流量控制属于通信双方协商;拥塞控制涉及通信链路全局。
流量控制需要通信双方各维护一个发送窗、一个接收窗,对任意一方,接收窗大小由自身决定,发送窗大小由接收方响应的TCP报文段中窗口值确定;拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。
实际最终发送窗口 = min{流控发送窗口,拥塞窗口}。
| 状态码 | 类别 | 含义 |
|---|---|---|
| 1XX | Informational(信息性状态码) | 接收的请求正在处理 |
| 2XX | Success(成功状态码) | 请求正常处理完毕 |
| 3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
| 5XX | Server Error(服务器错误状态码) | 服务器处理请求出 |
100 Continue :表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响应。
close_wait状态是在TCP四次挥手的时候收到FIN但是没有发送自己的FIN时出现的,服务器出现大量close_wait状态的原因有两种:
处理方法:
65536.因为TCP的报文头部中源端口号和目的端口号的长度是16位,也就是可以表示2^16=65536个不同端口号,因此TCP可供识别的端口号最多只有65536个。但是由于0到1023是知名服务端口,所以实际上还要少1024个端口号。
而对于服务器来说,可以开的端口号与65536无关,其实是受限于Linux可以打开的文件数量,并且可以通过MaxUserPort来进行配置。
《TCP 拥塞控制算法简介》:https://yq.aliyun.com/articles/691978
《TCP快速重传为什么是三次冗余ack,这个三次是怎么定下来的?》:https://blog.csdn.net/u010202588/article/details/54563648
《TCP新手误区–数据校验的意义》:https://blog.csdn.net/bjrxyz/article/details/75194716
《TCP数据段格式+UDP数据段格式详解》:https://www.cnblogs.com/love-jelly-pig/p/8471181.md
《OSI七层模型与TCP/IP五层模型》:https://www.cnblogs.com/qishui/p/5428938.md
《TCP协议中的窗口机制——滑动窗口详解》:https://blog.csdn.net/m0_37962600/article/details/79951780
https://www.zhihu.com/question/34873227/answer/518086565
https://www.cnblogs.com/wqhwe/p/5407468.md