计算机网络：传输层

目录

 

一、传输层协议

1、因特网传输层的两个协议：UDP和TCP

二、用户数据报协议（UDP）

三、传输控制协议（TCP）

四、握手连接

1、三次握手建立连接（SYN, SYN+ACK, ACK）

2、四次握手关闭连接（FIN, ACK, FIN, ACK）

五、TCP滑动窗口

1、快速重传

2、延迟确认

3、选择性确认

4、TCP超时时间计算

5、拥塞

6、TCP定时器

六、常见问题

1、死锁问题

2、傻瓜窗口症候（Silly Window Syndrome）

---

一、传输层协议

传输层协议是端到端或进程到进程的协议。因特网的传输层可以为两个进程在不可靠的网络层上建立一条可靠的逻辑链路，可以提供字节流传输服务且可以进行流控制和拥塞控制。

• 流控制：控制双方的传送速率在双方可接受的范围内（TCP协议使用滑动窗口进行流控制）——防止大量数据同时发送给接收方；
• 拥塞控制：描述的是整个网络的状态，通过是否重传以及传输速率的大小去感知网络的拥塞情况然后进行相应的调整，达到恢复网络的目的——防止大量数据同时发送到同一个网络。

传输层的多路复用：（发送方）收集来自上层进程的数据形成数据段并发送出去；

传输层的解多路复用：（接收方）把收到的数据段交给正确的上层进程；

1、因特网传输层的两个协议：UDP和TCP

• UDP：提供不可靠的尽力服务；
• TCP：提供可靠的字节流服务，采用全双工的工作方式；
• TCP/UDP报文包含：IP头部+报文；
• 协议号：TCP=6,UDP=17,ICMP=1；
• 传输层的数据单元称为数据段（segment）；
• 因特网本身提供无连接的不可靠的尽力服务；
• UDP/TCP协议利用数据段中的目的端口号决定将收到的数据段交给哪个上层进程，其中0-1023为知名端口号（为提供知名网络服务的系统进程所用）；1024-49151为注册端口号（为企业软件所用）；49152-65535为动态端口（没有规定用途，一般用户可以随意使用，也称为私用或暂用端口号）；

二、用户数据报协议（UDP）

只提供无连接的不可靠的尽力服务。接收进程每次接收一个完整的数据报，如果进程设置的接收缓冲区不够大，收到的数据报将被截断。

端口号：用于关联发送进程和接收进程；

校验和：由伪IP头、UDP头和UDP数据报形成。其中伪IP头的协议号为17。发送方设置校验和为0时接收方会忽略校验和。

IP协议和UDP协议都提供了无连接不可靠的服务，但【UDP协议加上了端口号使得可以进行进程与进程之间的通信，而IP协议没有使用端口号，只能在主机和主机之间通信】。

三、传输控制协议（TCP）

为进程之间提供面向连接的可靠的数据传送服务。TCP为全双工协议，提供流控制机制，即控制发送方的发送速度使发送的数据不会”淹没“接收方。TCP还提供了拥塞控制功能。

• 字节流服务表示没有消息边界：多次发送的数据可以放在一个数据段中传送且不标识边界。（在TCP套接字编程中的表现为：可能会有多次send的内容只被一次recv接收）；
• 每个数据段的数据部分的最大长度不能超过MSS（Maximum Segment Size）；
• 每个TCP连接可以由四元组唯一标识：源IP地址、源端口号、目的IP地址、目的端口号。每个四元组的区别主要在于源端口地址，因为源端口地址可以是由系统分配（取一个未用的端口号来用），也可以由自己指定。
• TCP连接只能在两个进程之间建立，在传输过程中可能会丢失，从而可能导致数据段错序到达，但每个可达到另一端的数据段都是无比特错的。（即TCP提供无比特错的数据传送）

TCP报文格式：

• 字节流中的每个字节均被编号，初始序号采用基于时间的方案，一般采用随机数。数据部分的第一个字节的编号为初始序号加1；
• 每个数据段的序号采用其数据部分的第一个字节的编号，确认号为期待接收的下一个数据段的序号，只有设置了确认标志才有效。
• 通知窗口大小：用于通知发送方当前接收方的接收缓冲区剩余的空间，以调整发送方的发送窗口大小——流控制。（建立连接后接收方会先通知发送方自己的接收缓冲区的最大长度）；
• 紧急指针：用于指出带外数据（out-of-band）的边界，标志位URG为1时有效。（紧急数据不属于字节流）；
• 带外数据即是相对于普通字节流数据来说，优先被服务端接收处理的一部分数据。
• 
• 发送窗口：指明发送方还可以发送的字节序号范围（还可以发送多少字节）；
• 头部长度以四个字节为单位，校验和由伪IP头、TCP头部和TCP数据部分形成；
• SYN标志：同步序号，用来发起一个TCP连接，发送的数据点包含ISN（初始序号）（可理解为同步通信双方的序列号，保证可靠的数据传输）；
• FIN标志：结束标志，向对方表示自己不再发送数据；
• RST标志：重置连接，（因为连接出错）通知对方立即中止连接并释放相关资源；
• PSH标志：告知接收方发送方执行了推送操作，接收方需要尽快将所有缓存的数据交给接收进程。

TCP协议的工作过程：建立连接（非对称活动，只能由客户向服务器呼叫）->传送数据（全双工，对称活动）->释放连接（对称活动，可由任何一方发起）；

需要注意的是只有接收缓冲区里的数据被取走之后缓冲区才会空出相应的字节数。

四、握手连接

1、三次握手建立连接（SYN, SYN+ACK, ACK）

为实现可靠的数据传输，TCP协议的通信双方都必须维护一个序列号，以标识发送出去的数据报中哪些是已经被对方收到的。三次握手的过程即是通信双方互相告知序列号的起始值，并确认对方已经收到了序列号起始值的必经步骤。

• 客户端需要知道服务器的IP地址和端口号；
• 服务器收到客户端发来的连接请求（SYN报文）后查看是否有进程监听该端口（bind, listen），若有则将此连接请求传给进程，否则服务器发RST拒绝客户端。如果该进程接受连接请求，则发回SYN+ACK报文；
• 每一步采用超时重传，多次重发后将放弃；

详细过程：

• 第一次握手：客户端将标志位SYN置为1，随机产生一个seq=x并将数据报发送给服务器，随后客户端进入SYN_SENT状态，等待服务器确认。
• 第二次握手：服务器收到数据报后由标志位SYN=1知道客户端请求建立连接，服务器将标志位SYN和ACK都置为1，Ack=x+1，并随机产生一个seq=y，并将该数据报发送给客户端以确认连接请求，然后服务器进入SYN_RCVD状态；
• 第三次握手：客户端收到确认后，检查Ack是否为x+1，ACK是否为1。如果是则将标志位ACK置为1，Ack=y+1并将数据报发送给服务器。服务器检查Ack是否为y+1，ACK是否为1，如果是则成功建立连接，随后客户端和服务器都进入ESTABLISHED状态，完成三次握手，可以进行数据传输。

相关问题：

为什么不采用一次握手建立连接？

——如果服务器根本不存在或未打开，这时候继续发送数据报的话会浪费带宽，而且客户端需要服务器传来的初始序号和很多选项（比如发送窗口大小的确定）。

为什么不采用两次握手建立连接？

——两次握手建立TCP连接的话会出现恶意攻击的问题：客户端可以发送大量伪造源地址的连接请求，服务器确认后以为连接已经建立，最后会耗尽资源，进而拒绝所有合法的连接请求，无法正常提供服务。（DOS攻击）（但即使使用了三次握手，服务器也可能会因为遭遇恶意攻击而瘫痪，不过难度增加了很多）

 

 

2、四次握手关闭连接（FIN, ACK, FIN, ACK）

• FIN报文采用超时自动重发方式，在若干次重发后依然没有收到确认则发送RST报文给对方，然后强行关闭连接。
• 先发送FIN报文的一方在ACK发送完毕后需要等到2MSL(Maximum Segment Lifetime)的时间才能完全关闭连接（等待该连接的数据在因特网中消失）。

详细过程：

• 第一次握手：客户端发送一个FIN用来关闭客户端到服务器的数据传送，然后进入FIN_WAIT_1状态（主动发送FIN后的状态）；
• 第二次握手：服务器收到FIN后发送一个ACK给客户端，确认序号为收到的序号+1，然后服务器进入CLOSE_WAIT。此时TCP连接处于半关闭状态，即客户端已经没有要发送的数据，但服务端若发送数据客户端仍要接收。客户端收到服务器的ACK后处于FIN_WAIT_2状态。
• 第三次握手：服务器发送一个FIN来关闭服务器到客户端的数据传送，随后服务器进入LAST_ACK状态；客户端收到服务器的FIN报文后进入TIME_WAIT状态。
• 第四次握手：客户端发送一个ACK给服务器，确认序号为收到序号+1，随后服务器进入CLOSED状态，完成四次握手。客户端等待2MSL的时间后完全关闭连接。
• （若第二次握手和第三次握手同时发送，则客户端直接从FIN_WAIT_1状态进入TIME_WAIT状态）

五、TCP滑动窗口

• TCP协议使用选择性确认，不使用NAK；
• 只有一个超时定时器：一个TCP连接的发送方只有一个超时定时器，只针对未收到确认的第一个数据段启动；
• 只要发送或存在未确认的数据帧，就要启动超时定时器。
• 采用字节流的方式，每个数据段使用其第一个字节的编号作为序号，确认号为期待接收的下一个字节（下一个数据段）的序号。

1、快速重传

如果发送方收到一个数据段的3次重复的ACK（即总共收到4次），它就认为其后的数据段已经丢失，在超时之前会重传该数据段，这种方法称为快速重传（fast retransmit）。

2、延迟确认

采用延迟确认（delayed ACK）时，接收方并不在收到数据段时立即进行确认，而是延迟一段时间再确认。如果这个期间收到多个数据段，则只需要发送一个确认。如果在这个期间接收方有数据帧要发往发送方，还可以使用捎带确认（piggybacking），即服务器在发送数据给客户端时顺便发送确认号。

3、选择性确认

选择性确认允许接收方把收到的数据块通过数据段的选项告知发送方，使发送方不会重传这些数据块。

4、TCP超时时间计算

• EstimatedRTT：旧的往返时间；SampleRTT：当前采样得到的往返时间；RTO：超时定时器时间；

• 采样频率：若发送窗口为12MSS，则每12个段取样一次。

注意要区分：

每次重传时：直接把RTO加倍直到数据段首次得到确认；

收到非重传段ACK：则按上述的其他算法计算RTO，并将这个RTO作为后续段的RTO。

结合karn算法，一个TCP连接的发送方只有一个超时定时器且只针对未收到确认的第一个数据段启动。所以经过一个TTL（20ms）后第一个数据段重传（20ms），收到第一个数据段的重传确认帧后RTO加倍，并且启动第二个数据段（未确认）的超时定时器（40ms），超时之后再重传第二个数据段（20ms），收到第二个数据段的确认帧后RTO再次加倍，并且启动第三个数据段（未确认）的超时定时器(80ms），超时后再重传第三个数据段（20ms），至此三个数据段重传完成。总时间为20+20+40+20+80+20=200ms

5、拥塞

计算机网络的资源是有限的，若某段时间对网络中某一资源的需求超过了该资源所能提供的量，网络的性能就会下降，这种情况就是拥塞。

“太多的主机发送太快太多的数据给网络处理”。表现形式有：丢包（路由器缓冲区溢出）；长延迟（路由器缓冲区中排队）。

拥塞控制的方法（Congestion Control）：

• 端到端的拥塞控制：没有来自网络的明确的反馈；终端系统通过丢包和延迟推送的拥塞；TCP协议；
• 网络辅助的拥塞控制：路由器反馈给终端系统：用一个比特指出拥塞，向发送方发送一个明确的发送速率。

TCP拥塞控制：

• 超时或者收到3个重复ACK就认为丢包了，看作是拥塞发生了。
• TCP协议通过减少发送速率来控制拥塞，发送速率与发送窗口大小有关：rate=SWS(sending window size)/RTT。
• 引入拥塞窗口变量CongWin来限制SWS: SWS=Min(AdvWin,CongWin)，AdvWin为接收窗口大小。
• TCP协议改变CongWin的三种机制：加性增乘性减（AIMD）、慢开始、超时之后的保守方法。

加性增乘性减：

慢开始：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，即由小到大逐渐增加拥塞窗口的大小。

• 初始时，CongWin为1MSS，阈值为65535，发送一个数据段；
• 在当前窗口所有数据段的确认都收到之后，CongWin加倍：实际上每收到一个确认，CongWin增加一个MSS，把它称为慢开始是因为这个方法比立即采用通知窗口更慢。
• 拥塞发生时把当前CongWin的一半保存为阈值，然后CongWin又从1MSS开始慢开始。
• 当CongWin增长到等于或大于阈值时，在当前窗口所有数据段的确认都收到之后CongWin增加一个MSS，如果发生拥塞则按上一条描述的形式执行。
• 总结起来就是：一开始CongWin=1MSS，指数增长，当拥塞发生时设定一个阈值=当前CongWin/2，然后将CongWin置为1MSS，然后又开始指数增长，若CongWin增长到阈值，则接下来的增长变为线性增长（每次加1MSS）

慢开始和快速恢复：

• 快速恢复（Reno算法），是指发生拥塞后将CongWin设置为阈值，然后线性增长（每次加一个MSS）。
• 慢开始（Tahoe算法）：拥塞后CongWin从1MSS开始增长（指数增长，慢是指从1MSS开始）

6、TCP定时器

• 每个连接只针对第一个未确认数据段启动重传定时器（retransmission timer）。所有数据段都已确认，则关闭。超时重传或者发送窗口移动时要重启该定时器。
• 持续定时器（persist timer）：用于保持窗口大小信息流动，即使连接的另一端关闭了接收窗口。
• 保活定时器：在长时间没有交换数据段之后，检测连接的另一端是否出了问题。

六、常见问题

1、长肥管道问题

将一个连接看成是两个端点之间的管道，则其容量capacity(bits) = bandwidth(bits/sec) x round-trip-time(sec)

• 若发送窗口太小，管道远远达不到满载的状态，造成浪费：采用Window Scaling解决这个问题，SYN数据段选项用于设置WinScale，Window Size = Advertised Window * 2^(WinScale)，根据此方式来调整发送窗口的大小。
• 可能出现序号回绕的问题：采用给每个发送的数据报添加时间戳的方式(timestamp)，仅用于区分两个不同的数据报。（timestamp也可以用来测量RTT）
• 当丢包发送时，由于SWS的限制，管道将被清空：采用快速重传、快速恢复等方法。

2、死锁问题

解决方案：在发生窗口为0之后，发送方如果有数据要发送，则启动坚持定时器，定期从要发送的数据中取一个字节发送出去（Window Probe），直到收到不为0的通知窗口为止。

3、傻瓜窗口症候（Silly Window Syndrome）

情形1：发送进程有很多小批量数据要发送。

解决方案：

Nagle算法（启发式算法）：立即发送一个数据段（即使发送缓冲区只有一个字节）；只有收到上一个数据段的确认或者发送缓冲区中数据超过MSS才可以发送下一个数据。（对即时性要求高的地方，如鼠标操作，要关闭Nagle算法）

（收到确认才能继续发送）

情形2：接收进程频繁取走小批量数据。

解决方案：

Clark算法：当接收缓冲区的空闲块大小变得很小时，要等空闲块大小为接收缓冲区大小的一半或达到MSS时才发送确认。