动手学习TCP:总结和索引
TCP是一个十分复杂的协议,通过前面几篇文章只涉及了TCP协议中一些基本的概念。
虽然说都是一些TCP最基本的概念,但是试验过程中一直在踩坑,例如:TCP flag设置错误,seq、ack号没有计算正确,TCP状态变迁错误等等。
通过Pcap.Net真正实验一下才发现了很多TCP协议中要注意的细节,例如:Ack、Seq号的计算,EthernetLayer、IpV4Layer 、TcpLayer的层层包装,不同TCP flags的含义等等。
TCP中还有很多重要的内容,先做个记录,后面再深入了解。
- 往返时间测量
- 滑动窗口
-
拥塞避免算法
- 慢启动
- 快速重传和快速恢复算法
文章索引
简单总结
下面就对前面几篇文章中涉及到的TCP知识的进行简单的汇总。
TCP首部
- 在TCP首部中没有源和目标的IP、MAC地址(IP和MAC地址分别是网络层和链路层首部的信息),只有源和目标的端口
- Sequence Number是包的序号,网络层(IP层)的传输是不可靠的,可能产生包乱序,所以这个需要可以解决网络包乱序的问题
- Acknowledgement Number用来确认收到数据包的确认序号,为TCP的传输提供了可靠性保证
- TCP Flags包括了8个bit,通过对这些bit的设置,可以代表不同类型的TCP数据包
TCP连接建立和终止
三次握手
- 连接建立发起端发送[SYN]包,该端将主动打开(active open)
- 接收端将发送[SYN, ACK]包,该端将被动打开(passive open),ACK标志表示对收到的[SYN]包的确认
- 连接建立发起端发送[ACK]包确认[SYN, ACK]包
四次挥手
- 连接终止端(client)发送[FIN, ACK] 包,关闭client到server方向的数据发送通路
- server端发送[ACK]包来确认来自client的[FIN, ACK] 包
- server端发送[FIN, ACK] 包,关闭server到client方向的数据发送通路
- client端发送[ACK]包来确认来自server的[FIN, ACK] 包,到此TCP连接关闭
网络上的传输是没有连接的,包括TCP也是一样的。TCP所谓的"连接",其实是在通讯的双方维护一个"连接状态",让它看上去好像有连接一样。
TCP状态机的全部11种状态中:
- 客户端特有的状态:SYN_SENT、FIN_WAIT_1、FIN_WAIT_2、CLOSING、TIME_WAIT 。
- 服务端特有的状态:LISTEN、SYN_RCVD、CLOSE_WAIT、LAST_ACK 。
- 共有的状态:CLOSED、ESTABLISHED
客户端状态变迁
From State |
To State |
Recv Packet |
Send Packet |
CLOSED |
SYN_SENT |
- |
[SYN] |
SYN_SENT |
ESTABLISHED |
[SYN, ACK] |
[ACK] |
ESTABLISHED |
FIN_WAIT_1 |
- |
[FIN, ACK] |
FIN_WAIT_1 |
FIN_WAIT_2 |
[ACK] |
- |
FIN_WAIT_2 |
TIME_WAIT |
[FIN, ACK] |
[ACK] |
TIME_WAIT |
CLOSED |
- |
- |
服务器状态变迁
From State |
To State |
Recv Packet |
Send Packet |
CLOSED |
LISTEN |
- |
- |
LISTEN |
SYN_RCVD |
[SYN] |
[SYN, ACK] |
SYN_RCVD |
ESTABLISHED |
[ACK] |
- |
ESTABLISHED |
CLOSE_WAIT |
[FIN, ACK] |
[ACK] |
CLOSE_WAIT |
LAST_ACK |
- |
[FIN, ACK] |
LAST_ACK |
CLOSED |
[ACK] |
- |
当服务端收到客户端的TCP连接请求后,会发送[SYN, ACK]包,进入SYN_RCVD状态。如果没有收到客户端的确认,服务器会尝试重传,并保持SYN_RCVD状态一段时间(通常是30秒到2分钟)。
由于服务端的SYN_RCVD状态,就有了SYN Flood攻击。所谓的SYN Flood攻击就是,恶意的客户端给服务端发了一个SYN后,就下线了,通过这种方式来消耗服务器资源。
TIME_WAIT状态也称为2MSL(Maximum Segment Lifetime)等待状态,当TCP的一端进入TIME_WAIT状态后,所产生的效果就是该端口在2MSL这段时间中不能被再次使用。
TCP首部的RST位是用于复位的。一般无论合适一个报文端发往相关的连接出现错误,TCP都会发出一个复位报文段。主要使用:
- 访问不存在的端口的连接请求
- 异常终止一个连接
最大报文段长度表示TCP传往另一端的最大块数据的长度。当一个连接建立时,连接的双方都要通告各自的MSS。
一般,如果没有分段发生,MSS还是越大越好。报文段越大允许每个报文段传送的数据越多,相对IP和TCP首部有更高的网络利用率。当TCP发送一个SYN时,它能将MSS值设置为外出接口的MTU长度减去IP首部和TCP首部长度。对于以太网,MSS值可达1460。如果目的地址为非本地的,MSS值通常默认为536,是否本地主要通过网络号区分。
以太网和802.3对数据帧的长度都有一个限制,最大值分别是1500和1492个字节。链路层的这个指标称作MTU(注意MTU是链路层的概念),不同类型的网络大多数都有一个上限。
如果网络层(IP层)有一个数据报需要传输,且数据的长度比链路层的 MTU还大,那么网络层(IP层)就要进行分片(fragmentation),把数据报分成若干片,保证每一个分片都小于MTU;目的端的网络层(IP层)会对收到的分片进行重新组装。
TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力,这就是TCP的半关闭。
客户端发送FIN,另一端发送对这个FIN的ACK报文段。当收到半关闭的一端在完成它的数据传送后,才发送FIN关闭这个方向的连接,客户端再对这个FIN确认,这个连接才彻底关闭。
对于每个TCP连接,TCP管理4个不同的定时器
- 重传定时器使用于当希望收到另一端的确认。
- 坚持定时器(persist)使窗口大小信息保持不断流动,即使另一端关闭了其接收窗口。
- 保活定时器(keepalive)可检测到一个空闲连接的另一端何时崩溃或重启。
- 2MSL定时器测量一个连接处于TIME_WAIT状态的时间。
TCP keepalive和HTTP HTTP Keep-Alive
- HTTP协议的Keep-Alive意图在于连接复用,防止过多频繁的端连接造成TCP连接资源浪费
- TCP的keepalive机制在于保活、心跳,检测连接错误