共计 1134 个字符，预计需要花费 3 分钟才能阅读完成。
13.TCP
- TCP 与 UDP 的区别
他们都有特点，依据特点利用场景
| tcp | udp |
|---|---|
| 面向连贯，端到端，一对一 | 反对一对多 |
| 面向字节流的 | 面向报文的 |
| 传输牢靠，流量管制，超时重传 | 尽大致力传输，不牢靠 |
| 头部长，没有可选长度也要 20 个字节 | 头部开销少只有 8 个字节 |
- 为什么要有 tcp？
基于 ip 层的传输报文，不牢靠，tcp 牢靠
- tcp 实现了哪些性能？
牢靠传输，流量管制，拥塞防止，超时重传
- 三次握手的细节，为什么没有两次，或者 4 次
三次能够防止历史性连贯，同步双发的序列号，保障点对点有序通信，三次握手可能保障单方都确认对方已收到之前发给对方的包
三次能够搞定，没必要搞四次
三次握手单方的状态
| 客户端 | 服务端 |
|---|---|
| syn_send | syn_rec |
| establised | establised |
-
为什么是四次挥手，四次挥手的细节
为了保障客户端向服务端发送敞开连贯申请时，服务端还在向客户端传输的数据还能被客户端正确收到，在第二次挥手时，ack 和 fin 报文离开发送，ack 的确收到 fin 报文，fin 报文示意申请敞开与客户端的连贯
| 客户端 | 服务端 |
|---|---|
| fin_wait_1 | close_wait |
| fin_wait_2 | last_ack |
| time_wait(2msl) | close |
| close |
-
为什么是两个 MSL, 为什么要 time_wait?
如果没有 timewait, 客户端间接敞开，存在在路由的服务端向客户端传输数据无奈正确交付，timewait 能够实现单方的同步敞开，保障数据传输和承受的牢靠。
须要 TIME-WAIT 状态，次要是两个起因：
避免历史连贯中的数据，被前面雷同四元组的连贯谬误的接管；保障「被动敞开连贯」的一方，能被正确的敞开；- 对于分片的问题
mtu(最大传输单元)
mss(最小数据包)【见之前画的图】
- time_wait 次要呈现在被动敞开连贯的一方
在放弃长连贯时，有一方忽然断开连接了，因为 tcp 有保活机制，长时间没用信息交互时，回发送数据探测报文，如果收回的报文长时 间没有响应，就认为对方挂了，被动敞开连贯。
一个服务器的某个端口可能反对的最大 tcp 连贯数量次要取决于客户端的客户端的（ip 数 * 端口号）
-
如何解决 time_wait 过多的问题
- 关上 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 选项；
- net.ipv4.tcp_max_tw_buckets
-
程序中应用 SO_LINGER，利用强制应用 RST 敞开。
如果服务端要防止过多的 TIME_WAIT 状态的连贯，就永远不要被动断开连接，让客户端去断开，由散布在各处的客户端去接受 TIME_WAIT。
- 对于服务端半连贯和全连贯的问题？
服务器半连贯的状态是，收到了客户端的连贯申请了但还没有让客户端确认本人曾经承受
全连贯的状态是三次握手曾经实现之后