为了深入理解TCP协议, 我们需要了解TCP客户端/服务端的状态转移和正确性保持. 建议阅读Unix网络编程卷1第二章和第三章, 原书笔记

第二章的状态转移图

注：上图红框表示比较特殊的地方。

TCP状态转移图

上图中/符号左侧为收到的消息或发生的事件，/符号右侧表示响应的消息。比如SYN-RCVD左侧箭头上的"超时/RST"表示超时后会发送RST。

..后续看原文

TCP不同状态下的响应

第58行指明了当第三次握手失败时的处理操作，可以看出当失败时服务器并不会重传ack报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

书中提到的TCP问题

连接的建立和终止(握手) 2.6.1
SYN的TCP选项 2.6.2
状态转换中的同时开启与同时关闭第18章
TIME_WAIT状态 2.7
- 为什么该状态会持续2MSL.
  1. 可靠地实现TCP全双工连接的终止.
    - 如果最终的ACK丢失, 客户端可能要重传那个ACK
  2. 保证旧连接的重复分节在网络中消失.
    - TIME_WAIT状态的端口不可以建立新连接, 只有等该状态结束, 方可在原端口建立新连接
    - "TIME_WAIT状态的持续时间是MSL的2倍, 这足以让某个方向上的分组最多存活MSL秒即备丢弃, 另一个方向上的应答最多存活MSL秒也被丢弃". 我的理解是, 客户端收到FIN进入TIME_WAIT时, 服务端可能已经在此之前发过若干个"迷路了"的FIN, 还徘徊在网路中. MSL后, 这些FIN要么已经到达,要么则消逝了. 假如在MSL前收到了这批FIN, 则TIME_WAIT状态下的客户端自然要回复一批ACK. 这批ACK最多经过MSL时间会全部消逝.
    有人会说, 这只能确保在FIN出现迷路的场景下, 保证客户端收到的第一个FIN之前的那些迷路的FIN, 以及那些迷路FIN对应的ACK能在2MSL内消逝. 如果说FIN能正确送达,而ACK丢失, 那处于LAST_ACK状态的服务端就会不断重发FIN, 即使客户端到达了2MSL, 仍然可能有FIN在发送中
    针对这点, 文章开头的参考链接"若LAST_ACK一直收不到ACK怎么办"做了解释, 服务端发出FIN时, 客户端可能已经进入CLOSED状态, 于是回复一个RST, 强制关闭连接.
    我认为, 该文答案没有提到另一个例外, 就是客户端可能在TIME_WAIT状态结束后, 马上原地又建立了连接, 发送SYN, 进入SYN-SENT状态, 这时候, 如果服务端没收到SYN, 则客户端超时关闭socket; 如果收到了SYN, 则服务端正处于LAST_ACK状态. 我在状态转换图中没有看到当LAST_ACK收到SYN时会做什么行为, 有可能会返回RST(则客户端关闭socket), 或不返回任何报文(则客户端超时关闭socket). 这样的话, 都能保证客户端关闭socket.
- 为什么主动关闭端会处于TIME_WAIT. 因为主动关闭端可能需要重传最后的ACK.
accept前连接终止 5.11
第4章建议看原书笔记
- 4.3 connect三种出错返回情况(超时、拒绝、不可达), RST的产生条件
- 4.5 listen
  - 未完成连接队列(SYN_RCVD)+完成连接队列(ESTABLISHED)之和不超过backlog
  - SYN到达时，如果队列已满，TCP忽略该SYN分节. 忽略而不是发送RST的原因是希望客户端通过重传来再次尝试连接，这样服务器在有空闲队列后可以接受该连接。
  - 未完成的连接在超时未收到ACK后会被移除，一般取RTT大小，TCPv3指出该值为185ms
  - 在三路握手完成后，但在服务器调用accept 之前到达的数据应由服务器TCP排队，最大数据量为相应已连接套接字的接收缓存区大小
- SYN泛洪通过发送大量带有随机ip的SYN，充斥半连接队列，使得真正的SYN无法访问，造成denial of service。大量电脑分布式发动攻击可造成DDOS。
  - 解决方法：1. 降低SYN timeout 2. 设置SYN cookie防止重复ip攻击。感觉还是很难解决来自随机有效ip的攻击，具体做法还是专业人士来解决吧
第五章
- 5.7 展示了程序正常终止时连接的关闭方式。close会将socket的fd引用数减1，程序终止时也会关闭所有fd。当客户端socket的fd引用数为0时，内核会自动发送FIN，并转换状态FIN_WAIT_1，接到ACK后变为FIN_WAIT_2。
- 5.11 返回连接前终止。 Berkeley会在收到RST错误后自动从全连接队列里将socket去除，而大多数实现会让accept返回一个错误。
- 5.12 服务端进程终止。客户端阻塞在某个特定源的输入
- 5.14 客户端收到服务器发送的RST后，客户端继续读写会导致"Broken pipe"

6.4 利用select/poll修正客户端程序，写/读事件触发的条件
6.6 close与shutdown

常见TCP问题

TIME_WAIT过多的原因和解决
- 原因: 大量高并发地发起短连接, 导致大量连接开启后没发什么信息就关闭
- 解决: 客户端方面, 尽量转为长连接. 服务端方面, 应尽量让客户端来断开连接, 这样服务端能尽快进入CLOSED状态.

netstat检测TCP连接情况

通过netstat -a可以查看各个端口的连接状态, 如果是netstat -at则可以检测TCP连接.

recv-Q与send-Q含义

https://www.cnblogs.com/leezhxing/p/5329786.html
Use of Recv-Q and Send-Q

Recv-Q
Established: The count of bytes not copied by the user program connected to this socket.
Listening: Since Kernel 2.6.18 this column contains the current syn backlog.

Send-Q
Established: The count of bytes not acknowledged by the remote host.
Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.

Recv-Q
Established状态下表示某socket没被用户程序接收的数据
Send-Q
Established状态下表示某socket没被远程主机ACK的数据

一些理解

如果是半连接队列中超时的连接，会由服务器关闭并发送RST。如果是由于队列满无法接受的连接，会直接抛弃（不必发送RST，以便客户端重传机制再连接）。

tcp详解 netstat理解