传输层
传输层：负责端与端之间的数据传输；TCP/UDP
端口：
uint16_t （0-65535，0-1023不推荐使用；在一台主机上唯一标识一个进程
操作系统拿到网卡接受的数据，通过端口就知道数据改放在哪一个socket的缓冲区中
一个端口号只能被一个进程使用；一个进程可以使用多个端口号
五元组：一条网络上的数据包含的五条信息：源IP+源端口+目的IP+目的端口+协议
主机上网络状态的查看：netstat -anptu
传输层的传输协议：
-
UDP： 无连接，不可靠，面向数据报
-
面向数据报： 数据整条收发；灵活性低；但是不会造成粘包问题
-
udp协议包含字段： 源端口，目的端口，数据报长度，校验和
源端口/目的端口： 传输，确定数据应该哪个进程处理
校验和： 二进制的反码求和
数据报长度： uint16_t
udp提供整条数据向应用层交付（不会出现半个数据，因为头部中有报文长度标识）也正是因为数据报长度在协议头中有标识，因此udp不会产生粘包问题
uint16_t以为着UDP数据报最大长度是64k-8；若sendto给予的数据大于64k-8则会报错；
因为udp在传输层不会进行数据分段；
若传输数据大于64k，用户需要在应用层将数据分割成一个个小段进行传输；
udp传输并不保证数据报的有序到达；因此需要用户在应用层进行包序管理；
udp协议实现了传输层广播数据报； -
TCP： 面向连接，可靠传输，面向字节流
面向连接中的连接管理：三次握手+四次挥手
TIME_WAIT：
假若没有time_wait会有什么情况：最后一个ack丢失
被动关闭方重发FIN包，没有等待直接关闭若直接启动的客户端有使用相同端口信息，有可能受到FIN，对新连接造成影响
若新启动客户端使用相同端口信息，向服务端发送SYN请求，但是服务端因为没有受到最后一个ACK处于LAST_ACK状态，收到SYN后判断状态错误，回复RST报文重置连接，也对新连接造成影响
因此主动关闭方发送最后一个ack之后需要等待一段时间：两个MSL时间（MSL：报文最大生存时间）
1.处理若ack丢失，导致对端重传的FIN包
2.等待网络中所有双方延迟的报文消失在网络中，不会对后续造成影响相关问题
- 为什么握手是三次，而挥手是四次？
点击获取答案（若侵权，即删） - SYN泛洪攻击
产生原因： 攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。
解决方法： 1.降低SYN timeout时间，使得主机尽快释放半连接的占用；2. 采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文 - time_wait 的作用
点击获取答案（若侵权，即删） - 若服务端出现了大量的TIME_WAIT连接，为什么？如何解决？
点击获取答案（若侵权，即删）
- 为什么握手是三次，而挥手是四次？