【转】计算机网络——三次握手与四次挥手_三次握手和四次挥手

转载来源：网络编程知识预备(2) ——三次握手与四次挥手、流量控制(滑动窗口)、拥塞控制、半连接状态、2MSL

目录

• 一、三次握手
• • 什么是三次握手？
  • 三次握手图解
  • 过程解析：
  • • （1）第一次握手
    • （2）第二次握手
    • （3）第三次握手
• 二、四次挥手
• • 什么是四次挥手？
  • 四次挥手图解：
  • 过程解析：
  • • （1）第一次挥手
    • （2）第二次挥手(半连接)
    • （3）第三次挥手
    • （4）第四次挥手
    • 2MSL作用
    • 为什么连接是三次握手，关闭却要四次挥手(半连接)？
    • 连接中途客户端突然故障怎么办(保活计时器、探测报文段、心跳包)？
• 三、TCP流量控制(滑动窗口)
• 四、TCP拥塞控制
• • 慢开始
  • 拥塞避免
  • 快速重传

三次握手必须是客户端发起，四次挥手可以是客户端或服务器发起
主要看三个包：ACK（应答请求），FIN（请求结束），SYN（请求连接）

一、三次握手

什么是三次握手？

手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接。TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在“无差别”的网络之上。

TCP共有6个标志位，常见的：

建立起一个TCP连接需要经过“三次握手”

三次握手图解

过程解析：

（1）第一次握手

客户端发送SYN包（syn=j）到服务器，并进入SYN_SEND状态，等待服务器确认。

j是一个随机数，通过看服务器返回的j+1是否正确，判断第一次握手服务器是否正确响应。

（2）第二次握手

服务器确认客户的SYN包，同时发送ACK包（ack = j+1）作为回应；

自己也发送一个SYN包（syn=k），共两个包，此时服务器进入SYN_RECV状态；

k也是一个随机数，也是用于看客户端返回的k+1是否正确，判断第二次握手客户端是否正确响应。

（3）第三次握手

客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

二、四次挥手

什么是四次挥手？

和三次握手逻辑相同，非常相似。

四次挥手即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

四次挥手图解：

过程解析：

（1）第一次挥手

客户端发送一个FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态。

意思是说"我客户端没有数据要发给你了"，但是如果你服务器端还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据。

（2）第二次挥手(半连接)

服务器端收到FIN后，先发送ack=M+1，告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2 状态（半连接状态），继续等待服务器端的FIN报文。

（3）第三次挥手

当服务器端确定数据已发送完成，则向客户端发送FIN=N报文，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。服务器端进入LAST_ACK状态。

（4）第四次挥手

客户端收到FIN=N报文后，就知道可以关闭连接了。

但是他还是不相信网络，怕服务器端不知道要关闭，所以发送ack=N+1后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。服务器端收到ACK后，就知道可以断开连接了。

客户端等待了2MSL后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。

最终完成了四次握手。

2MSL作用

• 假设客户端最后一个确认报文段丢失，如果没有2MSL等待时间，那么服务端一直发送超时重发报文，最终无法进入CLOSED状态

• 2MSL时长可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中不会出现旧连接中的报文段

为什么连接是三次握手，关闭却要四次挥手(半连接)？

建立连接时，ACK和SYN可以放在一个报文里来发送。

而关闭连接时，被动关闭方可能还需要发送一些数据后，再发送FIN报文表示同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

说得尽可能具体一些就是

客户端发送FIN关闭报文，但是服务端仍在给他发送数据不能马上停止，服务端先给出ACK报文回应（你的请求我收到了，但要等我发完数据才能关闭哦）。当服务端发送完毕后，再发送FIN报文请求关闭，所以这两个报文不能同时发送，故有了四次挥手。

连接中途客户端突然故障怎么办(保活计时器、探测报文段、心跳包)？

TCP还设计有一个①保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。

服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个②探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

另外的：如果客户端没有数据发送，又不想断开的话还要发③心跳包，心跳包这个数据没用，只是告诉服务器我客户端还在【长连接】。

三、TCP流量控制(滑动窗口)

四、TCP拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫做网络拥塞。

• 在计算机网络中数位链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

当输入的负载到达一定程度吞吐量不会增加，即一部分网络资源会丢失掉，网络的吞吐量维持在其所能控制的最大值，转发节点的缓存不够大这造成分组的丢失是拥塞的征兆。

TCP的四种拥塞控制算法

• 1.慢开始
• 2.拥塞避免
• 3.快重传
• 4.快恢复

假定：
1.数据是单方向传送，而另一个方向只传送确认
2.接收方总是有足够大的缓存空间，因而发送发发送窗口的大小由网络的拥塞程度来决定
3.以TCP报文段的个数为讨论问题的单位，而不是以字节为单位

示例如下：
传输轮次：发送方给接收方发送数据报文段后，接收方给发送方发回相应的确认报文段，一个传输轮次所经历的时间就是往返时间RTT(RTT并非是恒定的数值），使用传输轮次是为了强调，把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个报文段的确认，拥塞窗口cwnd会随着网络拥塞程度以及所使用的拥塞控制算法动态变化。

在tcp双方建立逻辑链接关系时， 拥塞窗口cwnd的值被设置为1，还需设置慢开始门限ssthresh,在执行慢开始算法时，发送方每收到一个对新报文段的确认时，就把拥塞窗口cwnd的值加一，然后开始下一轮的传输，当拥塞窗口cwnd增长到慢开始门限值时，就使用拥塞避免算法。

慢开始

假设当前发送方拥塞窗口cwnd的值为1，而发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2，

发送方此时可以连续发送两个数据报文段，接收方收到该数据报文段后，给发送方一次发回2个确认报文段，发送方收到这两个确认报文后，将拥塞窗口的值加2变为4，发送方此时可连续发送4个报文段，接收方收到4个报文段后，给发送方依次回复4个确认报文，发送方收到确认报文后，将拥塞窗口加4，置为8，发送方此时可以连续发送8个数据报文段，接收方收到该8个数据报文段后，给发送方一次发回8个确认报文段，发送方收到这8个确认报文后，将拥塞窗口的值加8变为16，

当前的拥塞窗口cwnd的值已经等于慢开始门限值，之后改用拥塞避免算法。

拥塞避免

也就是每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。同理，16+1……直至到达24，假设24个报文段在传输过程中丢失4个，接收方只收到20个报文段，给发送方依次回复20个确认报文段，一段时间后，丢失的4个报文段的重传计时器超时了，发送发判断可能出现拥塞，更改cwnd和ssthresh.并重新开始慢开始算法，如图所示：

快速重传

发送方发送1号数据报文段，接收方收到1号报文段后给发送方发回对1号报文段的确认，在1号报文段到达发送方之前，发送方还可以将发送窗口内的2号数据报文段发送出去，接收方收到2号报文段后给发送方发回对2号报文段的确认，在2号报文段到达发送方之前，发送方还可以将发送窗口内的3号数据报文段发送出去，

假设该报文丢失，发送方便不会发送针对该报文的确认报文给发送方，发送方还可以将发送窗口内的4号数据报文段发送出去，接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段，发送方还可以将发送窗口中的5号报文段发送出去,接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段,，发送方还可以将发送窗口内的最后一个数据段即6号数据报文段发送出去，接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段，

此时，发送方收到了累计3个连续的针对2号报文段的重复确认，立即重传3号报文段，接收方收到后，给发送方发回针对6号报文的确认，表明，序号到6为至的报文都收到了，这样就不会造成发送方对3号报文的超时重传，而是提早收到了重传。