TCP 三次握手 四次挥手以及滑动窗口

TCP 三次握手

简介：

TCP头部结构： 

 对上图的详细介绍：

         （4）RST 标志，表示要求对方重新建立连接。我们称携带 RST 标志的 TCP 报文段为复位报文段。

三次握手流程以及解释： 

下面是一张很生动形象的三次握手图： 

有人可能会觉得两次握手也可以，但是客户端和服务端都要确定自己是能发数据也能收数据的，也要确定对方是否能收发数据。这样的连接才安全可靠，所以需要三次握手。

接下来确定每次握手确定了什么：

第一次握手：客户端确定了自己有发送能力。服务端确定自己有接收能力以及客户端的发送能力。

第二次握手：客户端确定了自己有接收能力以及服务端有发送和接收(能发送消息说明第一次握手成功)能力。服务端确定自己有发送能力。这里客户端自己需要的以及服务端需要的都确定好了。

第三次握手：服务端确定了客户端有接收能力。这里服务端自己需要的以及客户端需要的都确定好了。

当然也可以将第二次握手拆成两次握手（4次握手），这样也是可以的。要保证连接的可靠至少要3次握手。

注意第三次握手时发送方就可以携带一些数据了。

只有当ACK标记为1的时候，ack确认序号才有用。 

第一次握手：
    1.客户端将SYN标志位置为1
    2.生成一个随机的32位的序号seq=J ， 这个序号后边是可以携带数据（数据的大小）
 
第二次握手：
    1.服务器端接收客户端的连接： ACK=1
    2.服务器会回发一个确认序号： ack=客户端的序号 + 数据长度 + SYN/FIN(按一个字节算)
    3.服务器端会向客户端发起连接请求： SYN=1
    4.服务器会生成一个随机序号：seq = K
 
第三次握手：
    1.客户端应答服务器的连接请求：ACK=1
    2.客户端回复收到了服务器端的数据：ack=服务端的序号 + 数据长度 + SYN/FIN(按一个字节算)

加上SYN/FIN的原因：

为了确保确认序号的准确性，包括了SYN和FIN的长度是必要的。考虑到TCP头部中标志位的长度，将它们的长度也加入确认序号的计算，可以确保在建立或关闭连接时，确认序号的值正确地表示了已经接收到的数据的范围。

序号以及确认序号：

seq = 110(3)(会随机生成)表示发送了3个字节，ack = 113。表示已经接收到了你发送的3个字节，并希望你下一次给我发送的数据的序号从113开始。这样就可以确定数据的完整性。多次发送的数据通过发送报文的序号(排列序号)来保证顺序。

漫画图：

 上图中后4次表示通信过程。

TCP 四次挥手

简介：

漫画图： 

 一些细节：

为什么第二次挥手不和第三次挥手合并到一起呢？

因为当二次挥手的时候同意了对方的断开请求，但是自己还不想主动断开。因为可能还有一些数据需要处理，要等剩余的数据发送完毕才断开连接。

那么为什么三次握手的时候不分开呢？

因为建立连接是双方都愿意的事情，前面三次握手也说过三个握手也可以变为四次握手。

TCP 滑动窗口

简介：

对于窗口的理解：

发送方的缓冲区：
    白色格子：空闲的空间
    灰色格子：数据已经被发送出去了，但是还没有被接收
    紫色格子：还没有发送出去的数据
 
接收方的缓冲区：
    白色格子：空闲的空间
    紫色格子：已经接收到的数据

 

上图虚线框一个是6k，向右滑动。

# mss: Maximum Segment Size(一条数据的最大的数据量)
# win: 滑动窗口
1. 客户端向服务器发起连接，客户端的滑动窗口是4096，一次发送的最大数据量是1460
2. 服务器接收连接情况，告诉客户端服务器的窗口大小是6144，一次发送的最大数据量是1024
3. 第三次握手
4. 4-9 客户端连续给服务器发送了6k的数据，每次发送1k
5. 第10次，服务器告诉客户端：发送的6k数据以及接收到，存储在缓冲区中，缓冲区数据已经处理了2k,窗
口大小是2k
6. 第11次，服务器告诉客户端：发送的6k数据以及接收到，存储在缓冲区中，缓冲区数据已经处理了4k,窗
口大小是4k
7. 第12次，客户端给服务器发送了1k的数据
8. 第13次，第一次挥手，客户端主动请求和服务器断开连接，并且给服务器发送了1k的数据
9. 第14次，第二次挥手，服务器回复ACK 8194, a:同意断开连接的请求 b:告诉客户端已经接受到方才发的2k的数据
c:滑动窗口2k
10.第15、16次，通知客户端滑动窗口的大小
11.第17次，第三次挥手，服务器端给客户端发送FIN,请求断开连接
12.第18次，第四次挥手，客户端同意了服务器端的断开请求