计算机网络查漏补缺--中

4. 传输层

"传输层"的功能，就是建立"端口到端口"的通信。相比之下，"网络层"的功能是建立"主机到主机"的通信。只要确定主机和端口，我们就能实现程序之间的交流。

"端口"是0到65535之间的一个整数，正好16个二进制位。0到1023的端口被系统占用，用户只能选用大于1023的端口。不管是浏览网页还是在线聊天，应用程序会随机选用一个端口，然后与服务器的相应端口联系。因此，Unix系统就把主机+端口，叫做"套接字"（socket）。有了它，就可以进行网络应用程序开发了。

4.1 UDP协议

⽬标和源端⼝：主要是告诉 UDP 协议应该把报⽂发给哪个进程。

包⻓度：该字段保存了 UDP ⾸部的⻓度跟数据的⻓度之和。

校验和：校验和是为了提供可靠的 UDP ⾸部和数据⽽设计，防⽌收到在⽹络传输中受损的 UDP 包。

UDP也是遵循“上层变动不改动下层”。由"标头"和"数据"两部分组成。

"标头"部分主要定义了发出端口和接收端口，"数据"部分就是具体的内容。然后，把整个UDP数据包放入IP数据包的"数据"部分，而前面说过，IP数据包又是放在以太网数据包之中的，所以整个以太网数据包现在变成了下面这样：

UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都会产生一个UDP数据报，并组装成一份待发送的IP数据报，这与面向字节流的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系（主要是在传输层就进行分段了，因此不会受IP分片的影响）。

UDP的校验和

UDP的校验和，UDP对首部和数据部分都进行校验，而IP首部的校验和仅对IP的首部进行校验。TCP的校验和也是对首部和数据部分都进行校验，另外，UDP的校验和是可选的，而TCP的是必选的。

不可靠协议

UDP是不可靠的协议，没有超时和重传功能，当UDP数据封装到IP数据报传输时，如果丢失，会发送一个ICMP差错报文给源主机，另外，如果UDP数据报的发送端没打开UDP校验和，而接收端计算校验和有差错，那么UDP数据报将会被丢掉，也不会发送ICMP差错报文。

4.2 TCP协议（传输层）

UDP协议的优点是比较简单，容易实现，但是缺点是可靠性较差，一旦数据包发出，无法知道对方是否收到。

为了解决这个问题，提高网络可靠性，TCP协议就诞生了。这个协议非常复杂，但可以近似认为，它就是有确认机制的UDP协议，每发出一个数据包都要求确认。如果有一个数据包遗失，就收不到确认，发出方就知道有必要重发这个数据包了。

因此，TCP协议能够确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。

TCP数据包和UDP数据包一样，都是内嵌在IP数据包的"数据"部分。TCP数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常TCP数据包的长度不会超过IP数据包的长度，以确保单个TCP数据包不必再分割。

源端口和目的端口：加上IP首部的源IP地址和目的IP地址，确定唯一的一个TCP连接。另外通过目的端口来决定TCP将数据报交付于那个应用程序，从而实现TCP的分用功能。

状态位：SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等。TCP 是面向连接的，因而双方要维护连接的状态。

ACK：仅当ACK=1时确认号字段才有效，当ACK=0时，确认号无效。TCP规定，在连接建立后所有的传送报文段都必须把ACK置1。

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

• 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；

• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；

• 字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。

4.2 TCP通过以下方式提供可靠性(面试)：

1、应用程序被分割成TCP认为最合适发送的数据块。这点与UDP完全不同，应用程序产生的UDP数据报长度将保持不变，加上IP首部后，才会进行IP分片。

2、当TCP发出一个报文段后，它会启动一个超时定时器，等待目的端发确认收到这个报文段，如果没能及时收到该确认信息，则将重发这个报文段（超时重传，最重要核心）。

3、当TCP接收端收到发送端发来的TCP报文段时，它将发送一个确认，这个确认不是立即发送的，通常会推迟几分之一秒。

4、TCP将保持它首部和数据的校验和。这是一个端到端的校验和，如果收到的报文段的校验和有差错，TCP将丢弃该报文段，同时不发送确认收到的消息，从而使发送端超时重发。

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

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

7、由于IP数据报有可能发生重复，TCP的接收端必须丢弃重复的数据

4.3 TCP连接三次握手

• 开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端⼝，处于 LISTEN 状态。

• 

• 客户端会随机初始化序号（ client_isn ），将此序号置于 TCP ⾸部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报⽂。接着把第⼀个 SYN 报⽂发送给服务端，表示向服务端发起连接，该报⽂不包含应⽤层数据，之后客户端处于 SYN-SENT 状态。

• 服务端收到客户端的 SYN 报⽂后，⾸先服务端也随机初始化⾃⼰的序号（ server_isn ），将此序 号填⼊ TCP ⾸部的「序号」字段中，其次把 TCP ⾸部的「确认应答号」字段填⼊ client_isn + 1 , 接着把 SYN 和 ACK 标志位置为 1 。最后把该报⽂发给客户端，该报⽂也不包含应⽤层数据， 之后服务端处于 SYN-RCVD 状态。

• 客户端收到服务端报⽂后，还要向服务端回应最后⼀个应答报⽂，⾸先该应答报⽂ TCP ⾸部 ACK 标志位置为 1 ，其次「确认应答号」字段填⼊ server_isn + 1 ，最后把报⽂发送给服务端，这次 报⽂可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。

• 服务端收到客户端的应答报⽂后，也进⼊ ESTABLISHED 状态。

4.4 为什么是三次握⼿？不是两次、四次？

  原因一：避免历史连接（首要原因）

  客户端连续发送多次 SYN 建立连接的报文，在网络拥堵情况下：

• 一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；

• 那么此时服务端就会回一个 SYN + ACK 报文给客户端；

• 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。

  原因二：同步双方初始序列号

  TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：

• 接收方可以去除重复的数据；

• 接收方可以根据数据包的序列号按序接收；

• 可以标识发送出去的数据包中， 哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

  序列号在 TCP 连接中占据着⾮常᯿要的作⽤，所以当客户端发送携带「初始序列号」的 SYN 报 ⽂的时候，需要服务端回⼀个 ACK 应答报⽂，表示客户端的 SYN 报⽂已被服务端成功接收，那当服务 端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样⼀来⼀回，才能确保双⽅ 的初始序列号能被可靠的同步。

  两次握⼿只保证了⼀⽅的初始序列号能被对⽅成功接收，没办法保证双⽅的初始序列号都能被确认接收。

  原因三：避免资源浪费

  如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？

  如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

  不使⽤「两次握⼿」和「四次握⼿」的原因：

  「两次握⼿」：⽆法防⽌历史连接的建⽴，会造成双⽅资源的浪费，也⽆法可靠的同步双⽅序列号；

  「四次握⼿」：三次握⼿就已经理论上最少可靠连接建⽴，所以不需要使⽤更多的通信次数。

4.4 TCP四次挥手

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。

• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。

• 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。

• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态（主动关闭连接的，才有 TIME_WAIT 状态。）

• 服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。

客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

4.5 为什么挥⼿需要四次？

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。

服务端收到客户端的 FIN 报⽂时，先回⼀个 ACK 应答报⽂，⽽服务端可能还有数据需要处理和发 送，等服务端不再发送数据时，才发送 FIN 报⽂给客户端来表示同意现在关闭连接。

从上⾯过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN ⼀般都会分开发送，因此是需要四次挥⼿。

4.6 为什么A在TIME—WAIT状态必须等待2MSL时间呢？

1、为了保证A发送的最后一个ACK报文段能够到达B。该ACK报文段很有可能丢失，因而使处于在LIST—ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B可能会重传这个FIN+ACK报文段，而A就在这2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入CLOSED状态。如果A在TIME—WAIT状态不等待一段时间就直接释放连接，到CLOSED状态，那么久无法收到B重传的FIN+ACK报文段，也就不会再发送一次确认ACK报文段，B就无法正常进入CLOSED状态。

2、防止已失效的请求连接出现在本连接中。在连接处于2MSL等待时，任何迟到的报文段将被丢弃，因为处于2MSL等待的、由该插口（插口是IP和端口对的意思，socket）定义的连接在这段时间内将不能被再用，这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

补充： 当客户端执行主动关闭并进入TIME—WAIT是正常的，服务端执行被动关闭，不会进入TIME—WAIT状态，这说明，如果终止了一个客户程序，并立即重启该客户程序，则新的客户程序将不再重用相同的本地端口，而是使用新的端口，这不会带来什么问题，因为客户端使用本地端口，而并不关心这个端口是多少。但对于服务器来说，情况就不同了，服务器总是用我们熟知的端口，那么在2MSL时间内，重启服务器就会出错，为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

4.7 TCP与UDP协议区别

1. 连接 TCP 是⾯向连接的传输层协议，传输数据前先要建⽴连接。 UDP 是不需要连接，即刻传输数据。

2. 服务对象：TCP 是⼀对⼀的两点服务，即⼀条连接只有两个端点。 UDP ⽀持⼀对⼀、⼀对多、多对多的交互通信。

3. 可靠： TCP 是可靠交付数据的，数据可以⽆差错、不丢失、不重复、按序到达。 UDP 是尽最⼤努⼒交付，不保证可靠交付数据。

4. 拥塞控制、流ᰁ控制: TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。 UDP 则没有，即使⽹络⾮常拥堵了，也不会影响 UDP 的发送速率。

5. ⾸部开销: TCP ⾸部⻓度较⻓，会有⼀定的开销，⾸部在没有使⽤「选项」字段时是 20 个字节，如果使⽤了 「选项」字段则会变⻓的。 UDP ⾸部只有 8 个字节，并且是固定不变的，开销较⼩。

6. 传输⽅式: TCP 是流式传输，没有边界，但保证顺序和可靠。 UDP 是⼀个包⼀个包的发送，是有边界的，但可能会丢包和乱序。

7. 分⽚不同: TCP 的数据⼤⼩如果⼤于 MSS ⼤⼩，则会在传输层进⾏分⽚，⽬标主机收到后，也同样在传输层组 装 TCP 数据包，如果中途丢失了⼀个分⽚，只需要传输丢失的这个分⽚。 UDP 的数据⼤⼩如果⼤于 MTU ⼤⼩，则会在 IP 层进⾏分⽚，⽬标主机收到后，在 IP 层组装完数据，接着再传给传输层。

4.8 TCP的交互数据流和成块数据流

4.8.1 交互数据流

捎带ACK

捎带ACK的意思是，当接收端接收到TCP报文段后，并不立即发送ACK报文，而是等上一段时间，如果这段时间里该主机有数据要发送到远程主机，就将该数据捎带上ACK一起发送过去，很明显，这样可以减少传输开销。为了防止产生超时重传，绝大多数情况下，这个等待时间为200ms，超过了200ms，如果没有数据要一起发送，就直接发送ACK报文。

Nagle算法

该算法的重点是要求在TCP连接上组多只能有一个未被确认的数据报在传输。算法的大致思路如下：应用程序把要发送的数据逐个字节地从到TCP的发送缓存，发送方把线面的一部分数据先发送出去，并把后面到达的字节继续缓存起来，当发送方收到前面字节的确认后，再把发送缓冲中的所有数据组装成一个报文段发送出去，同时继续对随后到来的数据进行缓存。只有收到前一个报文段的确认后才能继续发送下一个报文段。另外，Nagle算法还规定，当发送缓存中的数据已达到发送窗口大小的一半或已达到报文段的MSS值时，就立即发送一个报文段。

当数据到达较快而网络速率较慢时，用这种方法可明显地减少所用的网络带宽。很明显，该算法也是专门为交互性高的应用而设计的，对于成块数据流，如果每收到一次确认才能发送下一个报文段，那么传输速率就会很低。

4.8.2 成块数据流

对于一些数据吞吐量要求较高的应用，总是希望每次发送尽可能多的数据到主机，对于这类应用，TCP使用滑动窗口协议，该协议允许发送方在停止发送前和等待确认前可以连续发送多个分组，因此可以加速数据的传输。

滑动窗口

滑动窗口的滑动是以字节为单位的，发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小，发送方A根据B发送来的确认连接报文中标明的窗口的大小，来确定收到确认前的最大发送数据量，如果A接收到的B发来的确认报文中标明的窗口大小为0，则停止发送数据，直到收到不为0的确认报文，再继续发送。发送窗口表示在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去，凡是已发送过的数据，在没有收到确认前都要暂时保留，以便超时重传时使用。

注意：使用TCP滑动窗口协议时，接收方不必确认每一个收到的分组，在TCP中，ACK确认是累积的，可以在接收到几个序号连续的报文段后只发送一个ACK确认报文，但累积等待的时间最长不能超过0.5秒，以防止发送端超时重传。

发送接收缓冲区：

1、缓冲空间和序号空间都是有限的，并且都是循环使用的。

2、窗口大小一定不大于收发缓冲区的大小

3、发送缓冲区用来暂存发送方准备发送的TCP报文段和已发送但尚未收到确认的数据。

4、接收缓冲区用来暂按序到达但尚未被上层应用程序读取的数据未按序到达的数据。

4.9 TCP的流量控制机制（通过滑动窗口）

流量控制是为了让发送方发送速率不要过快，保证接收方来得及接收，防止分组丢失。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据。

如何控制

接收方每次收到数据包，可以在发送确认报文的时候，同时告诉发送方自己的缓存区还剩多少是空闲的，我们也把缓存区的剩余大小称之为接受窗口的大小，用变量wein来表示接受窗口的大小。

发送方收到之后，变回调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接受窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况。

发送方何时再继续发送数据

当发送方停止发送数据后，该怎样才知道自己可以继续发送数据？

当接受方处理好数据，接受窗口win>0，接受方发个通知报文去通知发送方，告诉他可以继续发送数据了。当发送方收到窗口大于0的报文时，就可以继续发送数据。

但是会出现，可能接受方发出的通知报文在网络传输中丢了，那么发送方一直接受不到继续传输的指令，那么双方就陷入僵局了。为了解决这个通知报文被丢失，我们当发送方收到接受窗口win=0时，发送方会停止发送报文，并同时开启一个定时器，每隔一段时间就发一个测试报文去询问接收方，打听是否可以继续发送数据了，如果可以就告诉他此时接受窗口的大小；如果接受窗口大小还是0，则发送方再次刷新启动定时器。

TCP规定，即使设置零窗口，也必须接受以下几种报文：

1.零窗口探测报文

2.确认报文

3.携带紧急数据的报文段

4.10  TCP的拥塞控制机制

计算机网络中的带宽、交换节点中的缓存和处理机等，都是网络的资源，在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况就叫做拥塞。

所谓拥塞控制，就是防止过多的数据注入到网络中，从而使网络中的路由器或链路不致过载。要注意用拥塞控制与流量控制的区别，拥塞控制是一个全局性的过程，涉及到所有的主机、路由器。

拥塞控制的算法有：慢开始、拥塞避免、快重传、快恢复四种。

慢开始（加倍）和拥塞避免（+1）

发送方维持一个拥塞窗口的状态变量，其大小取决于网络的拥塞程度，动态地变化，而发送窗口一般取拥塞窗口和对方给出的接收窗口的最小值（为了便于描述，后面的分析中假定对方给出的接收窗口足够大，这样将发送窗口等于拥塞窗口就可以了）。

慢开始算法的核心是从小到大逐渐增大发送窗口，也就是说，从小到大逐渐增大拥塞窗口的数值。通常在刚开始发送报文段时，先把拥塞窗口设置为一个最大报文段MSS的数值，而在每收到对上一轮报文段（，每次加倍后的报文段的个数，可能不止一个报文段）的确认后，就把拥塞窗口的数值加倍。

为了防止拥塞窗口增长过大引起网络拥塞，还需要维护一个慢开始门限的状态变量，当拥塞窗口的值小于慢开始门限时，使用慢开始算法，一旦拥塞窗口的值大于慢开始门限的值，就改用拥塞避免算法。

拥塞避免算法的思路是让拥塞窗口缓慢地增大，收到每一轮的确认后，将拥塞窗口的值加1，而不是加倍，这样拥塞窗口的值按照线性规律缓慢增长。

无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（没有按时收到确认），就把慢开始门限设置为出现拥塞时发送窗口值的一般，但最小不能小于2个MSS值，而后把拥塞窗口的值重新设置为1个MSS，执行慢开始算法。

快重传和快恢复

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（重复发送对前面有序部分的确认），而不是等待自己发送数据时才进行稍待确认，也不是累积收到的报文发送累积确认，如果发送方连续收到三个重复确认，就应该立即重传对方未收到的报文段（有收到重复确认，说明后面的报文段都送达了，只有中间丢失的报文段没送达）。

快恢复算法与快重传算法配合使用，其过程有如下两个要点：

1、当发送方连续收到三个重复确认时，就把慢开始门限减半，这是为了预防网络发生拥塞。注意，接下来不执行慢开始算法。

2、由于发送方现在认为网络很很可能没有发生特别严重的阻塞（如果发生了严重阻塞的话，就不会一连有好几个报文段到达接收方，就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口的值不设为1个MSSS），而是把拥塞窗口的值设为慢开始门限减半后的值，而后开始执行拥塞避免算法，线性地增大拥塞窗口。