在我的博客阅读本文
1. 基础
根据TCP/IP四层模型，在TCP场景下如下图：
其中，TCP头的信息：
2. 实战
2.1. 用Go写一个简单的TCP服务器与客户端
要分析TCP协议，尽管可以直接使用一个http的访问进行抓包，但是http的过程中又涉及DNS，ARP等过程混淆我们，为了纯粹的分析TCP协议，我们这里使用Golang写了一个简单的9830端口的TCP服务器与客户端，源代码简单展示如下：
服务端：
package server
import (
"fmt"
"net"
"os"
"strings"
"test/util"
)
func StartTCPServer(c chan<- string) {
listener, err := net.Listen("tcp", "localhost:9830")
if err != nil {
util.HandleError(err)
os.Exit(1)
}
defer listener.Close()
c <- "ready"
// 等待连接
conn, err := listener.Accept()
if err != nil {
util.HandleError(err)
os.Exit(1)
}
// 处理连接
handleRequest(conn)
}
func handleRequest(conn net.Conn) {
defer conn.Close()
var res strings.Builder
buf := make([]byte, 1024)
for {
n, err := conn.Read(buf)
if err != nil {
break
}
res.Write(buf[:n])
}
fmt.Print("Received client message, size:", res.Len())
}
客户端：
package client
import (
"fmt"
"net"
"os"
"strings"
"test/util"
)
func StartTCPClient() {
conn, err := net.Dial("tcp", "localhost:9830")
if err != nil {
util.HandleError(err)
os.Exit(1)
}
defer conn.Close()
// 发送200kb消息
largeMessage := strings.Repeat("A", 200*1024)
_, err = conn.Write([]byte(largeMessage))
if err != nil {
util.HandleError(err)
os.Exit(1)
}
fmt.Println("Sent message to server!")
}
执行入口：
package main
import (
"fmt"
"sync"
c "test/internal/client"
s "test/internal/server"
)
// main wireshark filter express: tcp.port==9830
func main() {
var wg sync.WaitGroup
wg.Add(2)
serverReady := make(chan string, 1)
go func() {
s.StartTCPServer(serverReady)
wg.Done()
}()
go func() {
<-serverReady
c.StartTCPClient()
wg.Done()
}()
wg.Wait()
}
编译执行，控制台输出如下：
2.2. Wireshark抓包分析
由于我们这里TCP的客户端和服务端都是面向localhost ，使用adapter for loopback traffic capture接口捕获回环流量，过滤器过滤tcp端口9830即可：
tcp.port==9830
需要注意，即使代码和我一样，最终抓包的数据依然会有差距，因为MTU，window size等参数会因为OS的策略不同有差异，求同存异抓共性。
大体分为三部分：
- 协议连接建立与确认：即包号92~96部分，图中具体又分为两部分：
- 包号92~93中的Source和Destination都是::1，这个地址是IPV6的地址，类似于IPV4中的127.0.0.1。TCP客户端先尝试了连接IPV6的9830端口，被服务器中断（RST）。
- 包号94~96尝试了尝试了IPV4的9803端口，这一次得到了服务器的正确回应，开始了**
TCP协议中的“三次握手”，此时建立TCP连接**
- 具体的业务数据交互：即包号97~103
- 协议连接断开与确认：即包号104~107，也就是**
TCP协议中的“四次挥手”，此时释放TCP连接**
点开包号96，我们查看其Network层的数据情况：
Source Port之类的字段比较直观易于理解，下面我们重点看一下一些不太直观的字段代表的数据含义。
2.3. 限制数据包的大小——MSS与MTU
网络对包的大小是存在限制的，这部分是在建立TCP连接的“三次握手”中进行声明，即：
MSS（Maximum Segment Size，最大段大小）MTU（Maximum Transmission Unit，最大传输单元）：MSS+TCP头长度 +IP头长度即是MTU
在“三次握手中”，包号94中，客户端向服务端声明了MSS=65495 ，可以计算MTU（单位为Byte，一般Wireshark中出现的数字单位都是Byte）：
MTU = 65495 + 20(TCP头) + 20(IP头) = 65535
同理，包号95中，服务端在给客户端的ACK包中也声明了自己的MSS，也可以计算出MTU。
客户端和服务端各自有MTU，实际的传输包的大小是由客户端与服务端2个MTU中较小的数值去决定的。
2.4. 保证TCP的有序传输——Seq，Len与Ack
TCP提供的是有序传输，每个数据段都要标上一个序号。
在实际场景中，TCP传输数据时并不能严格保证有序，总会出现乱序的情况，需要根据序号进行排序。
Len：length，数据长度Seq：Sequence Number，序号，即上一个数据段Seq+Len，发送方和接收方都需各自维护Seq状态Ack：Acknowledge Number，确认号，待接受的数据序号,发送方和接收方都需各自维护Ack状态
以包号97~99为例：
- 97号：客户端发送数据，声明自己的
Seq=1，Len=65495 - 98号：服务端声明自己的
Seq=1，Len=0，同时计算Ack=65496，即发送方的Seq+Len - 99号：客户端发送数据，声明自己的
Seq=65496，Len=65495，ACK为1，即上一步中服务端的Seq+Len
可以推断出：
Seq和Len主要表达的是作为发送方当前的数据序号和长度Ack主要表达的是作为接收方的接收到的数据序号和长度的和TCP通信中，一个客户端/服务端既有发送的场景，也有接受的场景，因此Seq，和Ack都各自需要单独维护，Len则是实际的数据长度。
2.5. TCP头标志位——URG，ACK，PSH，RST，SYN，FIN
TCP头包含一系列的标识位（也称作控制位或标志位），它们用于控制和管理TCP连接的不同方面。每个标识位都占用TCP头部中的1个比特。
Wireshark不仅帮我们“翻译”了当前封包的状态，也把TCP头的所有状态位都做了提示。
- URG（紧急）：表示紧急指针字段（Urgent Pointer）有效，用于指示紧急数据。
- ACK（确认）：表示确认字段（Acknowledgment Field）有效。几乎所有的TCP报文，除了最初的SYN报文外，都会设置这个标志。
- PSH（推送）：提示接收端应该立即将这个报文交给应用层，而不是等待缓冲区满。
- RST（重置）：用于重置错误的连接，或拒绝非法的报文或打开的连接。
- SYN（同步）：在建立连接时用来同步序列号。当一个连接开始时，用来初始化序列号并开始连接建立。
- FIN（结束）：用于释放一个连接。当数据传输结束时，发送方用它来告诉接收方它已经结束发送数据。
2.6. TCP连接建立——三次握手
包号94~96行则为TCP的“三次握手”行为，发生在TCP连接建立之初：
“三次握手”主要分为3步：
- 客户端 → 服务端：【SYN】申请建立连接，声明初始
Seq - 服务端 → 客户端：【SYN，ACK】收到连接请求，声明初始
Seq，声明Ack=客户端声明的初始Seq+ 1 - 客户端 → 服务端：【ACK】收到确认请求，声明
Ack=服务端初始Seq+ 1
2.7. TCP连接释放——四次挥手
包号104~107行则为TCP的“四次挥手”行为，发生在TCP连接需要中断，释放连接时：
**“四次挥手”**主要分为4步，发起方可能是客户端，也可能是服务端：
- 发起方发起释放连接请求：【FIN，ACK】，声明
Seq和Ack - 接受方返回确认收到：【ACK】，声明
Ack=第1.步中发起方的Seq+ 1 - 接收方发起释放连接请求：【FIN，ACK】，声明
Seq和Ack（与上一步一样） - 发起方返回确认收到：【ACK】，声明
Ack=第3.步中接收方的Seq+ 1
2.8. 大包拆分——累计确认，TCP窗口
- 我们
TCP客户端代码中发送了一个200kb的字符串给服务端，之前分析过我们的MTU限制在65535b，不算TCP头和IP头的MSS为65495b。我们实际无法在一个数据帧中发送全部数据，需要按照MTU拆分为多个数据帧进行发送。 - 多个数据帧的发送不一定每一条都需要等待接收方回复ACK，可以发送若干条数据帧之后，接收方回复一条ACK即可，这是TCP的累计确认。
TCP连接的一方连续发送的数据帧数是存在限制的，否则无限发送数据帧，另一方处理速率赶不上就会遇到Back Pressure（背压）的情况，这个限制则是TCP Window(TCP窗口)，即Wireshark中的Win的数值：
- 包号95是三次握手的第二次，win=65535，这是声明自己的接受窗口大小是65535，在我们的例子中是服务端声明自己的接受窗口大小是65535，这是协商的初始窗口大小。
- 客户端按照
MTU/MSS要求拆分数据帧 - 包号97，客户端向服务端发送了
Len=65495的数据 - 包号98，服务端向客户端发送
ACK，调整了自己的TCP窗口，声明Win=2161152。这里如果窗口大小为零，发送方将停止发送数据，并等待下一个窗口更新。也就是说，窗口大小是动态调整的。 - 客户端获知服务端的窗口变大了，因此自己可以连续发送多个数据帧
- 包号99~101，客户端连续向服务端发送了3个数据帧，无需等待服务端回复
ACK，Seq按序增加，由于服务端没有回复ACK，这3帧数据的Ack都一样为1。 - 包号102，服务端向客户端发送了
ACK，Ack=204801，刚好是包号101的Seq+len，这里实际上代表当前客户端已经收到了包号99~101的内容，这被称为TCP的累计确认。
窗口大小在TCP协议设计之初只留了2byte，这个可以在Wireshark中看到：
后续为了提升Wireshark的长度，在TCP“三次握手”时的Options中有Window scale ：
最终窗口大小计算公式 = Window的数值 8442 * 2的window scale次方
2.9. 动态调整TCP窗口——从慢启动到阻塞避免
在上一部分大包拆分中，可以看到TCP窗口是会动态调整的，这是有一个具体的调整策略的。
- 连接刚建立，发送方对网络情况一无所知，需要定一个初始值，可以是几个MSS大小。
- 连接初期，由于发生拥塞概率很低，如果发出去的包都得到确认，可以尝试增大阻塞窗口，RFC建议是每收到n个确认，阻塞窗口就增大n个MSS，这个过程需要慢慢增长，称为慢启动过程。
- 持续一段时间后，窗口大小达到一个较大的值，发生拥塞的概率变大，不能继续使用慢启动的算法，需要再缓慢一点，RFC建议每个往返时间增加1个MSS，这个过程称为拥塞避免。
2.10. 丢包问题——RTO与快速重传
TCP连接过程中有可能出现丢包的情况。
对于发送方来说，如果发出去的包不像往常一样得到确认，有可能是网络延迟导致，发送方会等待一段时间再去判断，如果一直收不到，就会判定包已丢失，进行重传。这个过程称为超时重传，从发出原始包刀重传该包的时间段称为RTO：
重传之后，TCP窗口也会被调整，会先降到1个MSS，之后会进入慢启动过程。不过这次从慢启动到拥塞的临界窗口值有了参考依据，RFC5681建议应该设置为拥塞时没被确认的数据量的1/2，不小于2个MSS：
RTO的过程对性能影响是比较大的：
- RTO阶段等待重传不能传数据，浪费处理时间
- RTO之后的TCP窗口急剧减小，传输比之前慢
与RTO不同，如果拥塞很轻微，发生部分丢包，发送方还是能接收到部分Ack包，Ack会有期望Seq号，通过这个期望Seq号，发送方会意识到发生包丢失，当发送方收到3个及以上Dup Ack(重复确认)时会立刻重传，这个过程称为快速重传。
这里之所以需要凑齐3个及以上Dup Ack的原因是实际场景中包可能会乱序，Ack好像表现出一个缺失的包，但是这个包并没有丢失，而是由于乱序还在数据传输路上，可能很快就会传输过来，因此设置一个数量要求一定程度避免乱序导致快速重传：
快速重传的过程对性能影响是比较小的，因为依然有部分包能够被发送和接收到，说明拥塞并不严重，因此只需传慢一点即可，无需突然大幅度TCP窗口重新慢启动。RFC5681建议重新设置临时窗口为拥塞时没被确认数据的1/2，不小于2个MSS，拥塞窗口设置为临界窗口+3个MSS
2.11. 减轻网络负担可能降低性能——延迟确认与Nagle算法
- 延迟确认：如果收到一个包后暂时没什么数据要发给对方，那就延迟一段时间再确认；假设这段时间内恰好有数据要发出，则确认信息和数据可以在一个包里发。延迟确认减少了部分确认包，减轻了网络负担，但有时候会影响性能，带来传输数据延迟。
- Nagle算法：在发出去的数据还没有被确认之前，如果有小数据生成，就把小数据收集起来凑满一个MSS或者等收到确认后再发送。
3. 参考资料
- 林沛满 -《Wireshark网络分析就这么简单》
- 刘超 ——《趣谈网络协议》
