使用WireShark探究TCP传输过程

因为最近在搞OpenSSL加密通信，想看看加密传输的数据和不加密传输的数据有什么不同，所以就使用WireShark抓包软件一探究竟。突然发现WireShark抓包太强了，能清楚的看到TCP三次握手过程和数据传输过程，这也是这篇Blog的重点。

目录

不加密TCP传输

加密TCP传输

扩展

---

前提提醒：

1. 因为测试程序是公司的程序代码，所以不再提供（之后可能出一篇使用OpenSSL加密通信编程Blog）。
2. 使用WireShark软件抓包。要注意服务器和客户端是不是使用本地回环地址。如果是，走的是回环虚拟网卡，不走物理网卡。如果WireShark检测不了虚拟网卡就抓不了包（网上好像有解决方案，在这里不是重点）。当然你可以部署到不同机器上，下面就是使用该方法。
3. 以下服务器IP/PORT：192.168.18.165:11000 客户端IP：192.168.3.141

不加密TCP传输

直接看抓包结果：

可以清楚的看到TCP的三次握手，以及客户端服务器收发数据过程，包括发送大数据包，TCP采取发送端分包策略和接收端的延迟确认机制(见文末)等。

TCP理论知识：

• TCP数据包中，Seq表示这个包的序号，注意，这个序号不是按1递增的，而是按TCP包内数据字节长度加上，如包内数据是21字节，而当前A发到B的包的Seq是10的话，那下个A发到B的包的Seq就是10+21=31。
• 每个TCP包都带有Win、Ack，这些是告诉对方，我还可以接收数据的滑动窗口是多少，如果A发到B的包的Win为0，就是A告诉B说我现在滑动窗口为0了，饱了，你不要再发给我了，就说明A端环境有压力（如带宽满了等）。
• 如果A发到B连续几个包(不一定是数据包)，Seq号不变，Ack号一直在变大，说明A一直在收B的数据，一直在给B确认。
• 如果A发到B连续几个包(不一定是数据包)，Seq号一直变大，Ack号一直没变，说明A一直在向B发数据，没有发送确认，而是在等B的确认。
• 可以接收多个数据包后，一次性给一个确认，不用每个数据包一一对应给应答。

加密TCP传输

OpenSSL加密通信就是在TCP协议上再封装的一层协议，以供应用层使用。具体就不再细说，不是本Blog重点。

SSL握手

上图可以清楚看到，SSL协议的握手过程：

1. SSLclient通过Client Hello消息将它支持的SSL版本号、加密算法、密钥交换算法、MAC算法等信息发送给SSLserver。
2.  SSLserver确定本次通信采用的SSL版本号和加密套件，并通过Server Hello消息通知给SSLclient。假设SSLserver同意SSLclient在以后的通信中重用本次会话，则SSLserver会为本次会话分配会话ID（显然这里没有同意，而是在第四步创建一个新的Session）。并通过Server Hello消息发送给SSLclient；SSLserver将携带自己公钥信息的数字证书通过Certificate消息发送给SSLclient；SSLserver发送Server Hello Done消息。通知SSLclient版本号和加密套件协商结束。开始进行密钥交换。
3. SSLclient验证SSLserver的证书合法后，利用证书中的公钥加密SSLclient随机生成的premaster secret，并通过Client Key Exchange消息发送给SSLserver；SSLclient发送Change Cipher Spec消息，通知SSLserver兴许报文将采用协商好的密钥和加密套件进行加密和MAC计算；SSLclient计算已交互的握手消息（除Change Cipher Spec消息外全部已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSLserver。SSLserver利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，假设二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
4. SSLserver创建新的Session发送，接下来通信是用这个Session通信；SSLserver发送Change Cipher Spec消息，通知SSLclient兴许报文将采用协商好的密钥和加密套件进行加密和MAC计算；SSLserver计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSLclient。SSLclient利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，假设二者相同。且MAC值验证成功。则证明密钥和加密套件协商成功。

SSL传输数据

 

SSL加密的强大之处在于，在后续的传输中，可能会重新非对称加密，重新生成对称密钥，然后继续传输。
SSL之所以很难破解甚至无法破解，是因为算法都是利用一些大素数计算，计算起来也要半天，所以很难破解。

扩展

ACK机制：

• 发送方连续发送多个数据包或者一个数据很大被分为多个数据包（大小大于 MSS 的话，就会被打包成多个包）时，每次接收方并不是需要对每个连续的包进行ACK，可能接受几个包的时候发送ACK。而这些TCP数据包达到的顺序是不保证的，这样接收方可能先接收到后发送的TCP包。
• 为了降低网络流量，ACK有延迟确认机制。
• Ack的值到达最大值后，又会从0开始。

ACK延迟确认机制

接收方在收到数据后，并不会立即回复ACK,而是延迟一定时间。一般ACK延迟发送的时间为200ms，但这个200ms并非收到数据后需要延迟的时间。系统有一个固定的定时器每隔200ms会来检查是否需要发送ACK包。这样做有两个目的：

• 这样做的目的是ACK是可以合并的，也就是指如果连续收到两个TCP包，并不一定需要ACK两次，只要回复最终的ACK就可以了，可以降低网络流量。
• 如果接收方有数据要发送，那么就会在发送数据的TCP数据包里，带上ACK信息（见不加密TCP传输图中的客户端确认+发送数据）。这样做，可以避免大量的ACK以一个单独的TCP包发送，减少了网络流量。

 

PSH标志
TCP发送方什么时候将发送缓冲区数据发送出去，以及 接收方什么时候将数据从接收缓冲区读取都是未知的。如果使用 PSH 标志（但实际我们应用层控制不了，只是为了解释），上面这件事就确认下来了：

发送端：
对于发送方来说，由 TCP 自行决定，何时将接收缓冲区中的数据打包成 TCP 报文，并加上 PSH 标志（假设）。
一般来说，每一次 write，都会将这一次的数据打包成一个或多个 TCP 报文段（如果数据量大于 MSS（服务器端 MSS 为 1460，而客户端只有 1260） 的话，就会被打包成多个 TCP 段），并将最后一个 TCP 报文段标记为 PSH。
当然上面说的只是一般的情况，如果发送缓冲区满了，TCP 同样会将发送缓冲区中的所有数据打包发送。

接收端：
如果接收方接收到了某个 TCP 报文段包含了 PSH 标志，则立即将缓冲区中的所有数据推送给应用进程（read 函数返回）。
当然有时候接收缓冲区满了，也会推送。