愿打开本篇能对你有帮助。


计网基础 ·运输层_数据


文章目录


分层

网络协议通常分不同层次进行开发,每一层分别负责不同的通信功能。一个协议族,比如 TCP/IP,是一组不同层次上的多个协议的组合。 TCP/IP通常被认为是一个四层协议系统,如图 1 - 1所示

计网基础 ·运输层_网络_02

TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层,确认接收到的分组,设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信,因此应用层可以忽略所有这些细节。

而另一方面,UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机,但并不保证该数据报能到达另一端。任何必需的可靠性必须由应用层来提供。

这两种运输层协议分别在不同的应用程序中有不同的用途,这一点将在后面看到。

在TCP/IP协议族中,网络层IP提供的是一种不可靠的服务。也就是说,它只是尽可能快地把分组从源结点送到目的结点,但是并不提供任何可靠性保证。而另一方面,TCP在不可靠的IP层上提供了一个可靠的运输层。为了提供这种可靠的服务, TCP采用了​超时重传​、发送和接收端到端的确认分组(​三次握手​)等机制。由此可见,运输层和网络层分别负责不同的功能。


TCP/IP的分层

计网基础 ·运输层_网络_03

TCP和UDP是两种最为著名的运输层协议,二者都使用 IP作为网络层协议。

但是与TCP不同的是,UDP是不可靠的,它不能保证数据报能安全无误地到达最终目的。

域名系统

尽管通过IP地址可以识别主机上的网络接口,进而访问主机,但是人们最喜欢使用的还是主机名。在 TCP/IP领域中,域名系统(DNS)是一个分布的数据库,由它来提供 I P地址和主机名之间的映射信息。

现在,我们必须理解,任何应用程序都可以调用一个标准的库函数来查看给定名字的主机的IP地址。类似地,系统还提供一个逆函数—给定主机的IP地址,查看它所对应的主机名。

大多数使用主机名作为参数的应用程序也可以把 IP地址作为参数。

1.6 封装

当应用程序用 TCP传送数据时,数据被送入协议栈中,然后逐个通过每一层直到被当作一串比特流送入网络。其中每一层对收到的数据都要增加一些首部信息(有时还要增加尾部信息),该过程如图 1 - 7所示。

计网基础 ·运输层_tcpip_04

分用

当目的主机收到一个以太网数据帧时,数据就开始从协议栈中由底向上升,同时去掉各层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识,以确定接收数据的上层协议。这个过程称作分用(Demultiplexing),图1 - 8显示了该过程是如何发生的。

计网基础 ·运输层_数据_05

这些分层协议盒并不都是完美的。

客户-服务器模型

大部分网络应用程序在编写时都假设一端是客户,另一端是服务器,其目的是为了让服务器为客户提供一些特定的服务。

可以将这种服务分为两种类型:重复型或并发型。重复型服务器通过以下步骤进行交互:

I1. 等待一个客户请求的到来。
I2. 处理客户请求。
I3. 发送响应给发送请求的客户。
I4. 返回I1步。

重复型服务器主要的问题发生在 I2状态。在这个时候,它不能为其他客户机提供服务。

相应地,并发型服务器采用以下步骤:

C1. 等待一个客户请求的到来。
C2. 启动一个新的服务器来处理这个客户的请求。在这期间可能生成一个新的进程、任务或线程,并依赖底层操作系统的支持。
这个步骤如何进行取决于操作系统。生成的新服务器对客户的全部请求进行处理。处理结束后,终止这个新服务器。
C3. 返回C 1步。

并发服务器的优点在于它是利用生成其他服务器的方法来处理客户的请求。也就是说,每个客户都有它自己对应的服务器。如果操作系统允许多任务,那么就可以同时为多个客户服务。

一般来说, TCP服务器是并发的,而 UDP服务器是重复的,但也存在一些例外。

端口号

TCP和UDP采用16 bit的端口号来识别应用程序。那么这些端口号是如何选择的呢?

服务器一般都是通过知名端口号来识别的。例如,对于每个TCP/IP实现来说,FTP服务器的TCP端口号都是21,每个Telnet服务器的TCP端口号都是23,每个TFTP (简单文件传送协议)服务器的UDP端口号都是69。任何TCP/IP实现所提供的服务都用知名的1~1023之间的端口号。这些知名端口号由Internet号分配机构(Internet Assigned Numbers Authority, IANA)来管理。

到1992年为止,知名端口号介于1~255之间。256~1023之间的端口号通常都是由Unix系统占用,以提供一些特定的Unix服务—也就是说,提供一些只有Unix系统才有的、而其他操作系统可能不提供的服务。现在IANA管理1~1023之间所有的端口号。

客户端通常对它所使用的端口号并不关心,只需保证该端口号在本机上是唯一的就可以了。客户端口号又称作临时端口号(即存在时间很短暂)。这是因为它通常只是在用户运行该客户程序时才存在,而服务器则只要主机开着的,其服务就运行。

大多数TCP/IP实现给临时端口分配1024~5000之间的端口号。大于 5000的端口号是为其他服务器预留的(Internet上并不常用的服务)。我们可以在后面看见许多这样的给临时端口分


IP:网际协议

引言

IP是TCP/IP协议族中最为核心的协议。所有的TCP、UDP、ICMP及IGMP数据都以IP数据报格式传输。许多刚开始接触 TCP/IP的人对IP提供不可靠、无连接的数据报传送服务感到很奇怪。

不可靠的意思是它不能保证 I P数据报能成功地到达目的地。 IP仅提供最好的传输服务。如果发生某种错误时,如某个路由器暂时用完了缓冲区, IP有一个简单的错误处理算法:丢弃该数据报,然后发送ICMP消息报给信源端。任何要求的可靠性必须由上层来提供(如TCP)。

无连接这个术语的意思是 IP并不维护任何关于后续数据报的状态信息。

每个数据报的处理是相互独立的。这也说明,IP数据报可以不按发送顺序接收。如果一信源向相同的信宿发送两个连续的数据报(先是 A,然后是B),每个数据报都是独立地进行路由选择,可能选择不同的路线,因此 B可能在A到达之前先到达。


IP首部

计网基础 ·运输层_网络协议_06

IP数据报的格式如图3 - 1所示。普通的IP首部长为20个字节,除非含有选项字段。

分析图3 - 1中的首部。最高位在左边,记为 0 bit;最低位在右边,记为31 bit。 4个字节的32 bit值以下面的次序传输:首先是 0~7 bit,其次8~15 bit,然后16~23 bit,最后是24~31 bit。这种传输次序称作big endian字节序。由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序,因此它又称作网络字节序。以其他形式存储二进制整数的机器,如little endian格式,则必须在传输数据之前把首部转换成网络字节序。

目前的协议版本号是4,因此IP有时也称作IPv4。

尽管可以传送一个长达 65535字节的IP数据报,但是大多数的链路层都会对它进行分片。而且,主机也要求不能接收超过 576字节的数据报。由于 TCP把用户数据分成若干片,因此一般来说这个限制不会影响TCP。

事实上现在大多数的实现(特别是那些支持网络文件系统 NFS的实现)允许超过 8192字节的IP数据报。


Ping程序

引言

“ping”这个名字源于声纳定位操作。 ping程序由Mike Muuss编写,目的是为了测试另一台主机是否可达。该程序发送一份 ICMP回显请求报文给主机,并等待返回 ICMP回显应答

一般来说,如果不能 ping到某台主机,那么就不能 Telnet或者FTP到那台主机。反过来如果不能Telnet到某台主机,那么通常可以用 ping程序来确定问题出在哪里。ping程序还能测出到这台主机的往返时间,以表明该主机离我们有“多远”。


UDP:用户数据报协议

引言

UDP是一个简单的面向数据报的运输层协议:进程的每个输出操作都正好产生一个 UDP数据报,并组装成一份待发送的 IP数据报。

这与面向流字符的协议不同,如 TCP,应用程序产生的全体数据与真正发送的单个 IP数据报可能没有什么联系。

尽管相互独立,如果TCP和UDP同时提供某种知名服务,两个协议通常选择相同的端口号。这纯粹是为了使用方便,而不是协议本身的要求。

UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为 8字节(发送一份0字节的 UDP数据报是OK)。这个 UDP长度是有冗余的。 IP数据报长度指的是数据报全长,因此UDP数据报长度是全长减去 IP首部的长度(该值在首部长度字段中指定所示)。


UDP特征描述

用户数据报协议UDP只在IP的数据服务之上增加了很少一点功能,这就是复用和分用的功能以及差错检测功能。

1.UDP是无连接的。
2.UDP不保证可靠交付。
3.UDP是面向报文的,发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。
应用层交给UDP多长的报文,UDP就发送多少,因此应用程序必须选择长度合适的报文,
若报文太长,UDP把它交给IP层后,IP层传送时可能要进行分片,降低IP层效率。
4.UDP没有拥塞控制。
5.UDP首部开销很小,只有8个字节。
6.UDP支持一对一、一对多、多对一、多对多的交互通信。

所以,UDP将速度点满,但是稳定性就比较缺乏了。


UDP首部

计网基础 ·运输层_网络_07

伪首部仅仅是为了计算检验和。

(好可怜)

如果接收方UDP发现端口号不正确,就丢弃该报文,并由网际控制协议ICMP发送“端口不可达”差错报文给发送方。


UDP检验和

UDP检验和覆盖UDP首部和UDP数据。回想IP首部的检验和,它只覆盖 IP的首部—并不覆盖IP数据报中的任何数据。

UDP和TCP在首部中都有覆盖它们首部和数据的检验和。 UDP的检验和是可选的,而TCP的检验和是必需的。

如果发送端没有计算检验和而接收端检测到检验和有差错,那么 UDP数据报就要被悄悄地丢弃。不产生任何差错报文(当 IP层检测到IP首部检验和有差错时也这样做)。

UDP检验和是一个端到端的检验和。它由发送端计算,然后由接收端验证。其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。

尽管UDP检验和是可选的,但是它们应该总是在用。在 80年代,一些计算机产商在默认条件下关闭UDP检验和的功能,以提高使用UDP协议的NFS(Network File System)的速度。在单个局域网中这可能是可以接受的,但是在数据报通过路由器时,通过对链路层数据帧进行循环冗余检验(如以太网或令牌环数据帧)可以检测到大多数的差错,导致传输失败。不管相信与否,路由器中也存在软件和硬件差错,以致于修改数据报中的数据。如果关闭端到端的UDP检验和功能,那么这些差错在UDP数据报中就不能被检测出来。另外,一些数据链路层协议(如SLIP)没有任何形式的数据链路检验和。Host Requirements RFC声明,UDP检验和选项在默认条件下是打开的。它还声明,如果发送端已经计算了检验和,那么接收端必须检验接收到的检验和(如接收到检验和不为0)。但是,许多系统没有遵守这一点,只是在出口检验和选项被打开时才验证接收到的检验和。

IP分片

物理网络层一般要限制每次发送数据帧的最大长度。任何时候IP层接收到一份要发送的 IP数据报时,它要判断向本地哪个接口发送数据(选路),并查询该接口获得其MTU。IP把MTU与数据报长度进行比较,如果需要则进行分片。分片可以发生在原始发送端主机上,也可以发生在中间路由器上。把一份IP数据报分片以后,只有到达目的地才进行重新组装(这里的重新组装与其他网络协议不同,它们要求在下一站就进行进行重新组装,而不是在最终的目的地)。重新组装由目的端的 IP层来完成,其目的是使分片和重新组装过程对运输层( TCP和UDP)是透明的,除了某些可能的越级操作外。已经分片过的数据报有可能会再次进行分片(可能不止一次)。

尽管IP分片过程看起来是透明的,但有一点让人不想使用它:即使只丢失一片数据也要重传整个数据报。为什么会发生这种情况呢?因为 IP层本身没有超时重传的机制——由更高层来负责超时和重传(TCP有超时和重传机制,但UDP没有。一些UDP应用程序本身也执行超时和重传)。当来自TCP报文段的某一片丢失后,TCP在超时后会重发整个TCP报文段,该报文段对应于一份IP数据报。没有办法只重传数据报中的一个数据报片。事实上,如果对数据报分片的是中间路由器,而不是起始端系统,那么起始端系统就无法知道数据报是如何被分片的。就这个原因,经常要避免分片。

使用UDP很容易导致IP分片(在后面我们将看到, TCP试图避免分片,但对于应用程序来说几乎不可能强迫 TCP发送一个需要进行分片的长报文段)。


最大UDP数据报长度

理论上,IP数据报的最大长度是65535字节,这是由IP首部16比特总长度字段所限制的。去除 20字节的IP首部和8个字节的UDP首部,UDP数据报中用户数据的最长长度为65507字节。但是,大多数实现所提供的长度比这个最大值小。

我们将遇到两个限制因素。第一,应用程序可能会受到其程序接口的限制。 socket API提供了一个可供应用程序调用的函数,以设置接收和发送缓存的长度。对于 UDP socket,这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。现在的大部分系统都默认提供了可读写大于 8192字节的UDP数据报(使用这个默认值是因为 8192是NFS读写用户数据数的默认值)。

第二个限制来自于TCP/IP的内核实现。可能存在一些实现特性(或差错),使IP数据报长度小于65535字节。


UDP服务器的设计

来自客户的是 UDP数据报。IP首部包含源端和目的端 IP地址,UDP首部包含了源端和目的端的UDP端口号。当一个应用程序接收到 UDP数据报时,操作系统必须告诉它是谁发送了这份消息,即源IP地址和端口号。

这个特性允许一个交互 UDP服务器对多个客户进行处理。给每个发送请求的客户发回应答。

一些应用程序需要知道数据报是发送给谁的,即目的 IP地址。例如,Host Requirements RFC规定,TFTP服务器必须忽略接收到的发往广播地址的数据报。

这要求操作系统从接收到的 UDP数据报中将目的 IP地址交给应用程序。不幸的是,并非所有的实现都提供这个功能。

socket API以IP_RECVDSTADDR socket选项提供了这个功能。

大多数UDP服务器是交互服务器。这意味着,单个服务器进程对单个UDP端口上(服务器上的名知端口)的所有客户请求进行处理。

通常程序所使用的每个UDP端口都与一个有限大小的输入队列相联系。这意味着,来自不同客户的差不多同时到达的请求将由UDP自动排队。接收到的UDP数据报以其接收顺序交给应用程序(在应用程序要求交送下一个数据报时)。

然而,排队溢出造成内核中的UDP模块丢弃数据报的可能性是存在的。


TCP:传输控制协议

TCP的服务

TCP 是面向连接的运输层协议.
每一条 TCP 连接只能由两个端点(endpoint), 每一条 TCP 连接只能是点对点的.
TCP 提供可靠交付的服务. 通过 TCP 连接传送的数据, 无差错, 不丢失, 不重复, 并且能够按序到达.
TCP 提供全双工通信. TCP 连接的两端都设有发送缓存和接收缓存, 用来临时存放双向通信的数据.
面向字节流. TCP 中的流(stream)指的是流入到进程或从进程流出的字节序列.

TCP的连接是逻辑连接,虚拟连接,不是物理连接。

TCP 连接的端点叫做套接字 (socket),套接字=IP:port。


TCP通过下列方式来提供可靠性:

• 应用数据被分割成TCP认为最适合发送的数据块。这和 UDP完全不同,应用程序产生的数据报长度将保持不变。由TCP传递给I P的信息单位称为报文段或段(segment)

• 当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。

• 当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒。

• TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。

• 既然TCP报文段作为IP数据报来传输,而 IP数据报的到达可能会失序,因此 TCP报文段的到达也可能会失序。如果必要, TCP将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层。

• 既然IP数据报会发生重复,TCP的接收端必须丢弃重复的数据。

•TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。 TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

两个应用程序通过TCP连接交换8 bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务( byte stream service)。如果一方的应用程序先传 10字节,又传20字节,再传50字节,连接的另一方将无法了解发方每次发送了多少字节。收方可以分 4次接收这80个字节,每次接收 20字节。一端将字节流放到TCP连接上,同样的字节流将出现在TCP连接的另一端。

另外,TCP对字节流的内容不作任何解释。 TCP不知道传输的数据字节流是二进制数据,还是ASCII字符、EBCDIC字符或者其他类型数据。对字节流的解释由 TCP连接双方的应用层解释。

TCP的首部

TCP数据被封装在一个IP数据报中,

计网基础 ·运输层_原力计划_08

计网基础 ·运输层_原力计划_09

每个TCP段都包含源端和目的端的端口号,用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。


停止等待协议

其实这点已经是初见端倪了。前面说,UDP以稳定性换速度,那么TCP作为另一个传输协议,很自然的能想到其为稳定性放弃了一定的速度。

理想的传输有以下两个特点:

1、传输信道不产生差错

2、不管发送方以多块的速度发送数据,接收方总来得及处理收到的数据

很显然,目前不现实。

这里先讲一下停止等待协议:

计网基础 ·运输层_数据_10

每发完一个分组就停下来等待对方的确认,收到确认后再发送下一个分组。

接收端接收分组检测出现了差错, 就​丢弃分组​, 其它什么也不做.。发送端​超过了一段时间没有收到确认信息​, 即认为发送的分组丢失了, 因而重传前面发送过的分组, 叫​超时重传​。

所以,发送端必须​暂时保留已发送的分组的副本​, 只有收到相应的确认后才能清除保留的分组副本; 分组和确认分组​必须进行编号​, 这样才能明确是哪一个发送出去的分组收到了确认, 而哪一个分组还没有收到确认; 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些(网络时延)。

这里面细节很多,会引出很多东西。

确认丢失和确认迟到:

计网基础 ·运输层_原力计划_11

确认丢失: ​接收端发送的确认丢失了​。 这时发送端需要重传数据分组, 接收端又会收到这个分组, 接收端应该丢弃这个重复的分组, 并再次向发送端发送确认, 不能认为发送过确认就不再发送确认.

确认迟到: 接收端发送的确认迟到了, 接收端会收到重复的确认, 然后丢弃重复的确认. 接收端收到重复的分组, 丢弃重复的分组, 并重传确认分组.

利用确认和重传机制, 可以在不可靠的传输网络上实现可靠的通信, 上面这种可靠传输称为​自动重传请求​ ARQ(Automatic Repeat Request)


TCP/IP常见攻击

​[看雪2018峰会回顾] TCP的厄运,网络协议侧信道分析及利用​

了解一下哈,我哥说,我要走到那个位置,别的技术可以不用很深,但是一定要有足够的了解。这不还有些年嘛,时间紧迫了啊!!!

1、IP欺骗,伪造某台主机的 IP 地址的技术。我不会,不过没事没事,我有一个好兄弟跟我一样的喜欢在自己的领域深耕,他就是网络安全领域的。

2、SYN Flooding,这个我知道,我给你握两次手,第三次我不理你了嘿、、、然后你的资源就这样被我鸽干净了。

3、UDP Flooding,UDP 洪泛是也是一种拒绝服务攻击,将大量的用户数据报协议(UDP)数据包发送到目标服务器,目的是压倒该设备的处理和响应能力。防火墙保护目标服务器也可能因 UDP 泛滥而耗尽,从而导致对合法流量的拒绝服务。

大多数操作系统部分限制了 ICMP 报文的响应速率,以中断需要 ICMP 响应的 DDoS 攻击。这种缓解的一个缺点是在攻击过程中,合法的数据包也可能被过滤。如果 UDP Flood 的容量足够高以使目标服务器的防火墙的状态表饱和,则在服务器级别发生的任何缓解都将不足以应对目标设备上游的瓶颈。


4、TCP 重置攻击

问题不大,对长连接还有点用,短链接,等他破译了我的序列号,我早自己断开了。。

5、中间人攻击

攻击中间人攻击英文名叫 Man-in-the-MiddleAttack,简称「MITM攻击」。指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方 直接对话,但事实上整个会话都被攻击者完全控制。

6、DDOS

分布式拒绝服务。指的是处于不同位置的多个攻击者同时向一个或数个目标发动攻击,是一种分布的、协同的大规模攻击方式。

为什么需要运输层?

运输层向它上面的应用层提供通信服务,属于面向通信部分的最高层,同时也是用户功能中的最底层。

计网基础 ·运输层_网络_12

看图说话:

从IP层来说,通信的两端是两台主机。严格地讲,两台主机进行通信就是两台主机中的应用进程互相通信。

从运输层的角度看,​通信的真正端点并不是主机而是主机中的进程​。

可以看到,每台主机中都有不少于一个的进程,主机A中的AP1、AP2要和主机B中的AP3、AP4进行通信,却共用一个传输层,这说明传输层有很重要的功能:复用&分用。

​复用是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据​。

​分用时指接收方的运输层在去掉报文的首部后能够把这些数据正确交付目的应用进程​。

总结一下:网络层为主机之间提供逻辑通信,运输层为应用进程之间提供端到端的逻辑通信。

此外,运输层还向高层用户屏蔽了下面网络核心的细节。


计网基础 ·运输层_数据_13