五层协议之运输层

运输层

1.概述

当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务。

运输层提供的是应用进程间的逻辑通信，“逻辑通信”的意思是:运输层之间的通信好像是沿水平方向传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP。

2.端口号

1、思考

主机A使用QQ向PC发送了一组数据，数据在网络中经过传输后到达主机B，主机B对数据进行解包以后又是如何知道该数据是发送给哪个进程的呢?
TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。

2、端口号的值

• 端口号使用16比特表示，取值范围0~65 535
• 熟知端口号:0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如:FTP使用21/20，HTTP使用80，DNS使用53。
• 登记端口号:1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。例如: Microsoft RDP微软远程桌面使用的端口是3389。
• 短暂端口号:49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
• 常用端口号及对应的网络应用程序表格如下:

3.传输控制协议TCP

传输控制协议TCP (Transmission Control Protocol)一种基于连接的可靠的稳定的无重复的传输协议。

1、TCP头部信息

TCP协议头部信息如下:

• 16位源端口号(Source Port):发送主机中进程的端口号
• 16位目的端口号(Destination Port) :接收主机中进程的端口号
• 32位序列号(Sequence Number) :每一个包中都包含序列号，序列号被系统初始化为某个随机值ISN。后续的TCP报文段中序号加上该报文段所携带数据的第一个字节在整个字节流中的偏移。例如，某个TCP报文段传送的数据是字节流中的第1025~2048字节，那么该报文段的序号值就是lSN+1025
• 32位确认号(Acknowledgment Number):目的主机返回确认号，使源主机知道某个或几个报文段已被接收
• 四位首部长度（Header Length):由于TCP首部包含一个长度可变的选项部分，所以需要这么一个值来指定这个TCP报文段到底有多长
• URG标志:表示紧急指针(urgent pointer)是否有效
• ACK标志:表示确认号是否有效。我们称携带ACK标识的TCP报文段为确认报文段
• PSH标志:提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间（如果应用程序不将接收到的数据读走，它们就会一直停留在TCP接收缓冲区中)
• RST标志:表示要求对方重新建立连接。我们称携带RST标志的TCP报文段为复位报文段SYN标志:表示请求建立一个连接。我们称携带
• SYN标志的TCP报文段为同步报文段
• FIN标志:表示通知对方本端要关闭连接了。我们称携带FIN标志的TCP报文段为结束报文段16位窗口大小(window size):是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口(Receiver Window，RWND)。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度
• 16位校验和(TCP check sum):由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。
• 16位紧急指针(urgent pointer):是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。
• TCP头部选项∶TCP头部的最后一个选项字段(options)是可变长的可选信息。这部分最多包含40字节

2、TCP运输连接的阶段

建立TCP连接

数据传输

释放TCP连接

注意:三报文握手我们也称之为三次握手或者三路握手，四报文挥手我们也称之为四次挥手或者四路挥手

3.TCP连接的建立

TCP连接的建立需要解决以下三个问题:

• 使TCP双方能够确知对方的存在

• 使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)

• 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等)进行分配

三次握手过程:

• 由客户端的某个进程主动发起TCP连接建立，最初两端的TCP进程都处于关闭状态
• TCP服务器被动等待客户进程的TCP请求，所以TCP服务器进入监听状态
• TCP客户进程向TCP服务器进程发送TCP建接请求报文段，并且进入同步已发送状态
• TCP连接请求报文段首部中的同步位SYN被设置为1，表明这是一个TCP连接请求报文段，32位序列号字段seq被设置了一个初始值x，作为TCP客户进程所选择的初始序号。
• TCP服务器进程接收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并且进入同步已接收状态，该报文段首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段。序号字段seq被设置了一个初始值y，作为TCP服务器进进程选择的初始序号，确认号字段ack的值被设置成x+1，表明接收到了TCP客户进程序号为x的报文。
• TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并且进入连接已建立状态，报文段首部中的确认位ACK设置为1，表明这是一个普通的TCP确认报文段。序列号字段seq设置为x+1，确认号字段ack的值被设置成y+1，表明接收到了TCP服务进程序号为y的报文，TCP服务器进程收到该确认报文段后也进入连接已建立状态。

• TCP连接的建立可以使用二次握手吗？
  • 假设TCP客户进程发送了一个TCP请求报文段，但是该报文段在网络结点中被长时间滞留了，TCP客户采用超时重传机制重发TCP请求报文段并且被TCP服务进程接收，TCP服务进程发送一个TCP连接请求确认报文段，然后TCP服务进程和客户进程可以进行数据的传输，数据传输完成以后双方都处于关闭状态。
  • 随后滞留在网络结点中的那个失效的TCP请求报文段被TCP服务进程接收，TCP服务进程又发送一个TCP连接请求确认报文段，并且进入连接已建立状态，由于TCP客户进程并没有发起新的TCP连接请求，并且已经处于关闭状态了，因此不会理会TCP服务器发送的报文段，但是TCP服务器进程已经进入了连接已建立状态，他认为新的TCP连接已经建立好了，就会一直等待TCP客户进程发来数据，将会浪费TCP服务器主机的很多资源。

四次挥手过程: TCP通过四次挥手来释放连接，数据通信结束后，TCP双方都可以释放连接

• 假设由客户进程主动关闭TCP连接
• 客户进程发送连接释放报文段，并且进入终止等待1状态，该报文段中的首部终止位FIN设置位1，ACK设置为1，表明这是一个连接释放报文段，同时也对之前接收打报文段进行确认，seq=u表示TCP客户进程之前已发送过的数据的最后一个字节的序号+1，ack=v表示客户进程之前已收到的数据的最后一个字节的序号+1
• 服务器进程接收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并且进入关闭等待状态，此时TCP客户进程到服务器进程这个方向的连接就释放了，这时的TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了，但是TCP服务器进程如果还有数据需要发送，客户进程则还需要接收，这个状态可能会持续一段时间，直到TCP服务器进程将数据发送完毕。
• TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段。
• 当TCP服务器进程的没有数据要发送了后，释放连接（被动关闭)，TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。FIN=1，ACK=1表明这是一个连接释放报文段，seq=w,ack=u+1同时也对之前收到的报文段进行确认。思考:为什么seq=w，而不是seq=v+1呢?
• TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态
• TCP服务器进程收到该报文段后就进入关闭状态
• 而TCP客户进程还需要经过2MSL后才能进入关闭状态。MSL(Maximum Segment Lifetime)意思是最长报文段寿命，RFC793建议为2分钟。

思考:为什么TCP客户进程还需要经过2MSL后才能进入关闭状态?

• 假设TCP客户进程收到TCP连接释放报文段，并且针对该报文段发送普通的TCP确认报文段后马上进入关闭状态，但是该确认报文段丢失了，TCP服务器进程无法收到该确认报文段，TCP服务器程序就会以为之前发送的TCP连接释放报文段TCP客户进程没有收到，然后TCP服务器进程会对之前所发送的TCP连接释放报文段超时重传，并仍处于最后确认状态。由于TCP客户进程已经处于关闭状态了，不会处理TCP服务器进程发送的连接释放报文段,这样就会造成TCP服务器反复发送TCP连接释放报文段，并且一直处于最后确认状态而无法进入关闭状态。因此客户端等待2MSL可以确保服务器进程收到最后一个TCP确认报文。

4.TCP可靠传输的实现

1、分段传输: 应用数据根据MSS(Maxitum Segment Size最大分段大小，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes)所以往往MSS为1460）值被分割成TCP认为最适合发送的数据段。
注意:在运输层的分段传输（分组传输）和网络层的IP数据报分片传输的区别:分段传输只有TCP协议才有的，并且分段的依据为MSS，分片传输的依据为MTU。

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

3、CRC校验和: TCP将保持它首部和数据的检验和如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。

4、流量控制: TCP提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。接收方有即时窗口（滑动窗口)，随ACK报文发送。(TCP利用滑动窗口实现流量控制)

5、滑动窗口:

• 应答机制: 假如TCP每发送一个数据报，都要进行一次确认应答。当上一个数据包收到了应答了，再发送下一个，这个模式就有点像我和你面对面聊天，你一句我一句。这样的传输方式有一个缺点:**数据包的往返时间越长，通信的效率就越低。**为解决这个问题，我们可以使用累计

• 累计应答: 接收方在接收到多个数据包后再根据接收到的数据包进行应答，也称为累计确认。

• 窗口: 窗口的实现实际上是操作系统开辟的一个缓存空间，接收方根据实际情况在应答数据包中告知自己的接收窗口大小。**窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值（以字节为单位)。**发送方主机在等到确认应答返回之前，必须在缓冲区（发送窗口）中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

• 滑动窗口: 如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态;接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

  • 假设主机A发送数据给主机B，在建立TCP连接时，主机B在确认报文中将自己的接收窗口
    rwnd告知主机A。(假设接收窗口大小为400)
  • 主机A根据主机B的接收窗口大小创建自己的发送窗口（在内存上开辟一块空间缓存一个接收窗口大小的数据），并且假设每个数据包中载荷数据为100Bytes
  • 主机A分别将第一组数据（为了方便讲解假设seq=1，实际上应该为seq=ISN+1)，第二组数据(seq=101)、第三组数据(seq=201)、第四组数据(seq=301)发送给主机B，中间不需要等待主机B的应答数据报（累计应答)
  • 假设第三组数据(seq=201）在输出过程中被丢失了，尽管主机B接收到了第四组数据，但是因为累计应答时只应答最大连续报文，所以应答数据包中ack=201表示序号201之前的所有数据全部正确接收。假设主机B将接收窗口大小调整为300，在应答报文中rwnd=300。主机A接收到应答数据报后，将自己发送窗口中的序号1~200的数据删除，发送窗口往前
    (向右)移动并且将大小重新设置为300(开辟接收窗口大小的缓存序号为201-500的数据)
  • 主机B将序号为201，301，401的数据报发送给主机B
  • 假设以上三组数据报没有丢失，主机B在接收到所有数据后发送应答数据报，ack=501，并且将窗口调整为100，rwnd=100A
  • 主机A接收到应答数据报后，将自己发送窗口中的序号201~500的数据删除，发送窗口往前(向右)移动并且将大小重新设置为100(开辟接收窗口大小的缓存序号为501-600的数据)
  • 主机A将序号位600的数据报发送给主机B，按照以上逻辑知道数据发送完毕。

  

  • 接收窗口为0的处理: 当发送窗口被调整为0后，发送方就不能再发送数据了，假如接收方的接收窗口调整为大于0了，如果不采取特殊措施发送方是不知道的，因为接收方不会主动
    告知发送方自己接收窗口的大小。这时就需要持续计数器了，当发送方接收到接收窗口为0的应答报文时马上启动一个持续计时器，当定时达到时主动向接收方发送一个零窗口探测报文，该报文只携带一个字节的数据，然后这种逻辑直到接收方回复的接收窗口大于0。

5.用户数据报协议UDP

1、UDP概述

UDP是User Datagram Protocol的简称，中文名是用户数据包协议。

UDP是一种无连接的不可靠的传输协议(不需要进行三次握手和四次挥手)。

UDP不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的，因此适合实时数据传输，例如:IP电话、网络视频会议等实时应用。

2、UDP头部

3、UDP应用

使用UDP运输协议可以进行单播、多播和广播。

• 单播应用: DNS域名解析，域名系统是因特网上作为域名和IP(Internet Protocol Address)地址相互映射的一个分布式数据库。
  • 浏览器如何通过域名去查询URL对应的IP(对应服务器地址)呢?
    • 浏览器缓存:浏览器会按照一定的频率缓存DNS记录。
    • 操作系统缓存:如果浏览器缓存中找不到需要的DNS记录，那就去操作系统中找。
    • 路由缓存:路由器也有DNS缓存。
    • ISP的DNS服务器:ISP是互联网服务提供商(Internet Service Provider)的简称，ISP有专门的DNS服务器应对DNS查询请求
    • 根服务器:ISP的DNS服务器还找不到的话，它就会向根服务器发出请求，进行递归查询

• 当两个网络应用进程间需要快速传输大文件（音视频文件、图片文件等）时也可以使用
  UDP单播。
• 多播应用:网络视频会议、教学，视频监控等。IP多播(也称多址广播或组播）技术，是一种允许一台或多台主机(多播源）发送单一数据包到多台主机(一次的，同时的）的TCP/IP网络技术。IP多播通信必须依赖于IP多播地址，在IPv4中它是一个D类IP地址，范围从224.0.0.0到239.255.255.255。

• 广播的应用: ARP数据报广播

注意:在进行UDP编程时，UDP包的大小可以达到64k，但实际上MTU大小只有1k多，如果直接发一个超过MTU大小的包，就会在网络层被分片，这样的问题是，如果只要有一个分片在传输中出错了即校验不正确（这是较容易发生的)，整个传输的udp包就被丢弃。注意是整个而不是单个分片。这就是为什么发送UDP包通常也是1k多大小的原因。

6.TCP和UDP的区别

1、对比

除了上图所展示的区别外，使用TCP传输协议时，一旦建立好TCP连接后，系统需要实时的维护该连接，所以TCP所消耗的系统资源比UDP要多。

另外因为TCP的可靠性传输机制导致TCP传输数据时比UDP要慢的多。

2、TCP的长连接和短链接

• 长连接:TCP通信双方在建立好连接后，在较长一段时间内保持连接，直至某一方主动关闭连接。长连接多用于操作频繁，点对点的通讯，例如在物联网开发中某下位机需要定时地频繁向服务发送数据。
• 短链接:通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接。短连接多用于操作不频繁，点对点的通讯，例如:在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立━次连接，任务结束就中断连接。
• 对比

在较长一段时间内保持连接，直至某一方主动关闭连接。长连接多用于操作频繁，点对点的通讯，例如在物联网开发中某下位机需要定时地频繁向服务发送数据。

• 短链接:通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接。短连接多用于操作不频繁，点对点的通讯，例如:在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立━次连接，任务结束就中断连接。
• 对比