tcp详解 netstat理解

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

• TCP各种情况下的状态转换图
• 网络学习笔记：TCP 状态转换图
• 若LAST_ACK一直收不到ACK怎么办 和 https://stackoverflow.com/questions/40417087/how-if-the-last-ack-is-lost-in-tcp-termination

第二章的状态转移图

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

TCP状态转移图

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

..后续看原文

• TCP不同状态下的响应

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

书中提到的TCP问题

1. 连接的建立和终止(握手) 2.6.1
2. SYN的TCP选项 2.6.2
3. 状态转换中的同时开启与同时关闭 第18章
4. TIME_WAIT状态 2.7
   • 为什么该状态会持续2MSL.
     1. 可靠地实现TCP全双工连接的终止.
     • 假设所有消息都不会生存超过MSL时间. 那么被动关闭端最后的FIN可能在"迷失"后又正确抵达, 而接受到FIN的主动关闭端要正确响应ACK, 就需要FIN维持超过2MSL时间, 保证这段时间之后没有迷失的FIN
     • 如果TIME_WAIT方停留时间不足2MST, 可能出现:
       • 旧的TCP连接不存在了,系统只能返回RST包
       • 新的TCP连接备建立起来,延迟包可能干扰新的连接
     1. 保证旧连接的重复分节在网络中消失.
        • TIME_WAIT状态的端口不可以建立新连接, 只有等该状态结束, 方可在原端口建立新连接
   • 为什么主动关闭端会处于TIME_WAIT. 因为主动关闭端可能需要重传最后的ACK.
5. accept前连接终止 5.11
6. 第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的攻击，具体做法还是专业人士来解决吧
7. 第五章
   • 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，以便客户端重传机制再连接）。