图解TCP—3次握手&4次挥手

---

ForeWord

---

博主上一篇博文中提到TCP协议以面向连接的通讯方式保证了数据传输的可靠性。小伙伴们可以点击 →这里，详细了解(oﾟ▽ﾟ)o

那么本篇博文就详细描述它是如何通过面向连接保证数据传输可靠性的。

Key Ponit：

1. 3次握手4次挥手过程图解
2. 通讯过程中的滑动窗口机制

~tips：全文阅读需8min~

---

3次握手&4次挥手

---

下面以一次TCP通讯的时序图为例，详解通信过程。

在这个例子中，首先客户端主动发起连接、发送请求，然后服务器端响应请求，然后客户端主动关闭连接。

3次握手

解释：
1. 两条竖线表示通讯的两端，从上到下表示时间的先后顺序。
2. 数据一端传到网络的另一端需要时间，所以图中的箭头都是斜的。
3. 双方发送的段按时间顺序编号为1-3, 各段中的主要信息在箭头上标出。

下面详细解释图中3次握手的含义：

1.第一次握手

  客户端发出数据段1，向服务器发送连接请求。

TCP数据段解释：

1. SYN位置1表示连接请求。
2. 序号1000在网络通讯中用作临时的地址。每发一个数据字节，这个序号要加1，这样在接收端可以根据序号排出数据包的正确顺序，也可以发现丢包的情况。
3. mss表示最大段尺寸, 如果一个段太大，封装成帧后超过了链路层的最大帧长度，就必须在IP层分片，为了避免这种情况，客户端声明自己的最大段尺寸，建议服务器端发来的段不要超过这个长度。

另外，规定SYN位和FIN位也要占一个序号，这次虽然没发数据（有效载荷为0），但是由于发了SYN位，因此下次再发送应该用序号1001。

2.第二次握手

  服务器发送数据段2应答客户端的请求，同时也向客户端发送连接请求。

TCP数据段解释：

1. 带有SYN位，表示连接请求
2. 序号为8000，有效载荷为0
3. ACK位表示确认，且确认序号是1001。表示服务器对客户端发送消息：“我接收到序号1000及其以前所有的段,请你下次发送序号为1001的段“
4. 最大段尺⼨为1024


服务器的请求和应答在这一个段发出。

3.第三次握手

  客户端发出数据段3，ACK表示对服务器的连接请求进行应答。确认序号是8001

我们可以看到，3次握手不仅仅是建立连接，还会协调双方数据通信时的细节问题，比如最大段尺寸，还有下面要讲的滑动窗口等。

数据传输

成功连接到服务器后，就可以向它发送数据了，下图给出了数据传输的过程：

这里数据段中的序号和确认序号都是接着刚才连接时的数据往下传输的。

  客户端服务端对话过程详解：

4.客户端：“我向你发送了序号为1001的段，有效载荷是20字节。还有，我把你序号为8000及之前的数据段都接受完了，你下次给我发序号为8001的段。”

5.服务端：”好的，我给你发了序号8001的段，有效载荷是10字节。还有，我把你刚给我发的序号为1020及其之前的数据段都接收完了，你下次给我发序号为1021的段。“

6.客户端：“行，但我不发数据了。我把你刚给我发的序号为8010及其之前的数据段也都接收完了。你下次要发的话，就从8011开始发吧。”

这里注意几个细节：

     1.在数据传输过程中，为了保持传输可靠性。ACK和确认序号是非常重要的。

     2.应用程序交给TCP协议发送的数据会暂存在TCP层的发送缓冲区中，发出数据包给对方之后，只有收到对方应答的ACK段才知道该数据包确实发到了对方，可以从发送缓冲区中释放掉了。

     3.如果因为网络故障丢失了数据包或者丢失 了对方发回的ACK段，经过等待超时后TCP协议将也会自动将发送缓冲区中的数据包重发。  

Expand：全双工(full-duplex)与半双工(half-duplex)

全双工(full-duplex)

事实上，实际的TCP数据传输过程可以收发很多数据段, 虽然典型的情景是客户端主动请求服务器被动应答，但也不是必须如此，TCP协议为应用层提供了全双工(full-duplex)的服务，双方都可以主动甚⾄同时给对方发送数据。

半双工(half-duplex)

如果通讯过程只能采⽤用一问一答的方式，收和发两个方向不能同时传输，在同一时间只允许一 方向的数据传输，则称为”半双工(half-duplex)”。

4次挥手

客户端停止了数据传输，接下来就要断开连接了，这就是“挥手”的概念，下图给出了4次挥手的过程：

各数据段解释如下：

   7.客户端发出段7,FIN位表示关闭连接的请求。序号就不再解释了。

   8.服务器发出段8,应答客户端的关闭连接请求。

   9.服务器发出段9,其中也包含FIN位,向客户端发送关闭连接请求。

   10.客户端发出段10,应答服务器的关闭连接请求。 

通过数据段的描述，我们可以看出TCP链接与释放是基于状态机的。

Question&Answer

Question1：. 为什么连接时需要3次，断开时需要4次呢？

Answer：

连接时，服务器的请求和应答可以在一个段发出，而断开连接时服务器的应答和关闭连接请求通常不合并在一个段中，因为有连接半关闭的情况，这种情况下客户端关闭连接之后就不能再发送数据给服务器了，但是服务器还可以发送数据给客户端，直到服务器也关闭连接为止。

Question2：. 为什么连接时需要3次，2次可以吗？4次呢？

Answer：
因为3次握手任意少一个就会引起丢包问题甚至造成链接RST，而且再多的握手就会浪费资源，多一个报文都会浪费资源，4次挥手也是如此。

Question3：关于TIME_WAIT状态

在TCP 协议数据传输过程中，主动断开链接的一方要进入TIME_WAIT状态 。防止连接异常退出和数据丢失。具体请移步大神链接：TCP/IP详解–TIME_WAIT状态详解

---

滑动窗口(SlidingWindow)

---

流量控制

介绍UDP协议时博主描述了这样的问题：如果发送端发送的速度较快，接收端接收到数据后处理的速度较慢，而接收缓冲区的大小是固定的，就会丢失数据。

而TCP协议通过”滑动窗口(Sliding Window)”机制解决这一问题，滑动窗口win的数据就是实时接收端缓冲区大小。

重新审视通信过程

先来看看下图的通讯过程：

      和刚才一样，1-3表示3次挥手，4-12表示数据传输，13-18表示4次挥手。只不过这个例子中引入了滑动窗口，进一步保证了数据传输的可靠性。

下面具体分析一下各数据段代表的含义：

3次握手

1. 发送端发起连接,声明最大段尺⼨寸是1460，初始序号是0。窗口大小是4K，表示“我的接收冲区还有4K字节空闲，你发的数据不要超过4K”。
2. 接收端应答连接请求，声明最大段尺寸是1024，初始序号是8000。窗口大小是6K。
3. 发送端应答,三次握手结束。 

数据传输

4. 发送端发出段4-9,每个段带1K的数据。发送端根据窗口大小知道接收端的缓冲区满了, 因此停止发送数据。 

5. 接收端的应用程序提走2K数据接，收缓冲区又有了2K空闲。接收端发出段10，在应答已 到6K数据的同时声明窗口大小为2K。 

6. 接收端的应⽤用程序又提⾛走2K数据,接收缓冲区有4K空闲,接收端发出段11,重新声明窗口⼤小为4K。

4次挥手

7. 发送端发出段12-13，每个段带2K数据，段13同时还包含FIN位。 

8. 接收端应答接收到的2K数据(6145-8192)，再加上FIN位占一个序号8193。因此应答序号是8194，连接处于半关闭状态。接收端同时声明窗口大小为2K。 

9. 接收端的应用程序提走2K数据并重新声明窗口大小为4K。 
10. 接收端的应用程序提走剩下的2K数据，接收缓冲区全空。接收端重新声明窗口大小为6K。 
11. 接收端的应用程序在提走全部数据后，决定关闭连接。发出段17包含FIN位，发送端应答，连接完全关闭。

Other Problem

滑动窗口

上图在接收端用小方块表示1K数据，实心的小方块示已接收到的数据。虚线框表示接收缓冲区，因此套在虚线框中的空心⼩方块表示窗口⼤小，从图中可以看出，随着应用程序提走数据，虚线框是向右滑动的，因此称为滑动窗口。

TCP和UDP的另一个不同之处

    TCP：面向流的协议

从这个例子还可以看出：

发送端是1K-1K地发送数据，而接收端的应用程序可以2K2K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据。

也就是说，应用程序所看到的数据是一个整体,或说是一个流(stream)，在底层通讯中这些数据可能被拆成很多数据包来发送。但是一个数据包有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议。

    UDP：面向消息的协议

而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据。


---

The End

---

TCP3次握手和4次挥手是网络中非常重要的知识，对于从事IT行业的人来说，更应该搞懂它。

希望本文能对读者起到一定的帮助｡◕ᴗ◕｡