先介绍我们UDP/TCP协议缓冲区
在UDP和TCP在数据传输和介绍时有有缓冲区概念的。
UDP缓冲区
UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后 续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果 缓冲区满了, 再到达的UDP数据就会被丢弃;
TCP缓冲区
TCP在内核中是具有接收缓冲区和发送缓冲区的。
TCP和UDP由于他们的发送缓冲区和接收缓冲区是独立的（尽管udp没有真正发送缓冲区），所以使用TCP和UDP通信是全双工状态的。
udp协议报头介绍
报头也是结构体。
为了节约紧凑数据，降低内存对齐问题，我们的结构体使用位段结构。
不做数据浪费，tcp报头数据结构也是使用位段结构
UDP报头内容介绍
原端口号：发送方的端口号，接收方再给发送方发送数据时候，可以依据端口发送到对应的主机中特定的进程。
目的端口号：发送方机器上绑定该端口的进程。
UDP长度：整个UDP报文（报头+数据）长度，确定数据长度用的，UDP报头是固定的8字节，所以16位UDP报文长度-8字节就是数据长度。
16位UDP检验和：检测这次数据发送情况，如果有误直接将整个报文丢弃。
检验和的检测我们后面讲完TCP报文后一起说。
UDP协议注意事项
- 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
- 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层 返回任何错误信息;
- 面向数据报: 不能够灵活的控制读写数据的次数和数量
数据报文：报头固定，以一个一个报的发送方式，不考虑
无连接：意味着不需要链接就可以直接对某个服务器发送数据。
不可靠：这并不是一个贬义词而是中性词，不可靠意味着，我们发出数据后不用管数据是否抵达，我们只管发送就行了。不需要太多的编写和维护成本。
注意事项
UDP数据报文如果超过了64K数据，数据报会变成2个UDP报，我们需要手动拼接数据。
tcp协议报头介绍
TCP协议特点与报头内容
这里我们讲报头内容和特点是相辅相成的
确认应答机制：每条报文发送对方都会返回一条确认报文
对应使用的是32位序号和32位确认序号。
这两个选项都存在于tcp报文中，为什么不能直接用一个报文呢？
如果我们使用同一个序号，在client多次发送报文后，server将无法对client也发送报文只等应答所有报文，才可以发送数据，这是极其不合理的。只有你在发不让我发送？所以一般来说在通信的过程中，应答报文和常规通信报文是一起发送的，单纯应答报文不带数据的，所以对常规报文携带的数据不会有影响。
观察画图，会发现我们的应答报文的确认序号是发送报文序号+1。
也就是说，client发送序号:1000报文，server发送确认序号：1001报文。
这是为了, 告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发。
server发送确认序号：1001报文，告诉client我已经收到了1000报文，下次从1002开始发送。
这里的序号和确认型号分别还有知识点。
序号
在接收到多次数据时候，依托确认序号得知发送的序号。
因为在网络中传输数据的时候，发送3条报文的序号是，1000、2000、3000的。网络中是无序的，有可能接收方接收到的数据报文序号是，2000、1000、3000，这个时候如果是一份大的数据发送，我们需要将3条报文数据合并，但是必须得知道合并顺序，否则数据会乱序。
所以我们需要使用接收到的报文中的序号对报文重新排序。
确认序号
如果类似上面发送“床前明月光.....”大型报文，我们需要发送到多条报文才可以将全部数据发送完毕。所以我们发送了3条报文给server端，按道理来说我们需要对3条报文发送3次确认应答报文。但是这是没有必要的，server端会检测3条报文是否属于同组报文并且检测数据是否存在丢失，如果没有丢失数据，就应答最后序号的报文，发送应答报文，如果发现丢失数据，就发送丢失报文的前一个报文。
4位的首部长度
4位首部长度，是tcp报文的报头长度，4位比特位最大为15(1111)值，但是我们的标准报头就有20个字节，并且还有可能增加选项(选项也属于报头)，所以约定了，4位首部长度的单位是4字节，也就是说15*4=60个字节，也即是最大报文长度位60字节。但是一个tcp报文至少必须有标准报头20字节，所以4位首部长度范围是：5~15;
16位窗口大小
如果我们的client端一致给server发送报文，但是我们的server端真正处理一个重要的报文，也就是说发送速度和处理报文速率不相等，导致了server端的接收缓冲区满了或者快满了，这个信息必须通知发送方client。
servser当前缓冲区以使用980/1000，server需要使用一种发送将当前链接的接收缓冲区情况通知client，server将自己的接收缓冲区剩余情况发送给client。
偏移量数据，当出现紧急报文时候，立刻服务器立刻优先执行该报文，提托紧急数据选项，查看服务器情况。
到这里发现这6个位我们并没有介绍，我们在三次握手和四次挥手中一同介绍。
三次握手和四次挥手
三次握手
介绍报文类型：
- SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
- ACK: 确认号是否有效
- RST：链接重置（server重启，旧链接发送数据立刻会被链接重置；三次握手最后的ACK失败，但是client发送数据，被server要求链接重载）
我们的链接的过程其实就是三次握手的过程。
这三次握手必须是客户端和服务器都3次握手才是链接成功建立。
三次握手后，将公钥密钥的交流发挥到了极值
三次次握手的意义
1、防止低级SYN洪水
防止SYN洪水攻击，如果只有一次握手或者两次，恶意分子可以使用client端向我们的server发送大量的恶意的链接请求，并且自己不处于链接状态。
一次：恶意攻击，直接大量发送SYN报文，并且自己不处于链接状态。
二次：对方链接建立成功，给我们返回ACK报文，直接丢弃，不建立链接。
大量的链接需要服务器维护为该链接的缓冲区，数据结构等等，当到了一定的数量，服务器将再也接收不了链接，甚至崩溃。
为什么3次链接可以有效预防被一台client搞崩的情况呢？
一般而言都是client向server发送链接请求的，在最后一次握手client发送ACK报文后处于先链接状态，而server只有在接收到ACK报文才会处于链接态，说明了client必须链接成功才能让server链接成功，client和server维护相同数量的链接以相关结构体数量。一般而已，server的能力远大于client，所以一台设备client攻击服务器，自己先会崩溃。（但是如果几十万台服务器同时攻击，这就不是三次握手能解决的了）
而三次握手
Client必须承受和Server一样的链接数量。
2、测试全双工通路
client发送SYN给server后，接收到server发送的SYN+ACK，证明了client的接收通路和发送通路畅通
server接收client发送的SYN后，发送SYN+ACK，进入等待后再次接收到ACK确认应答，证明了 server的接收通路和发送通路畅通。
四次挥手
链接断开时需要做的工作。
FIN: 通知对方, 本端要关闭了
断开链接需要双方同时做四次挥手的动作：client端做4次挥手动作，server端也要做4次挥手动作。就像签署离婚协议一样，需要双方签字才生效。
我们server调用close关闭套接字。
理解 CLOSE_WAIT 状态
服务器测试代码：我们只链接客户端，当客户端关闭的时候我们链接不退出。
服务器客户端一同启动。建立链接成功，我们查看一下链接情况。
因为我们使用的是本地链接所以链接是一样的，查看state,发现我们的client和server都处于ESTABLISHED状态，正常通信状态。
我们将客户端关闭。
再次观察连接情况
选择服务器server变成了CLOSE_WAIT状态并保持，客户端变成FIN_WAIT2状态，应证了如果client端发送断开链接，如果服务器在收到断开FIN后并没有执行close函数，关闭套接字的话，服务器和客户端依旧处于临界状态，并且这个状态不会随着时间而关闭，链接必须一定等待server调用close发送FIN才可打破这种状态。这是很关键的一个地方，如果链接一直未关闭，服务器过载将发送崩塌，我们该错误称之为文件描述符泄露。
理解TIME_WAIT状态
TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime) 的时间后才能回到CLOSED状态
如果是客户端关闭链接，就是客户端进入TIME状态，等待
如果是服务器关闭链接，就是服务端进入TME状态，等待
在TIME_WAIT状态下的一方会进入TIME_WAIT状态，依旧可以接收信息，在等待2MSL时间下下，一个MSL是在网络通信中最远距离通信的时间，这一般由各个linux确定，在Centos7上默认配置的值是60s。使用cat /proc/sys/net/ipv4/tcp_fin_timeout，查看MSL时长
为什么需要TMIE_WAIT状态呢？
- 防止在关闭后网络中依旧有的报文数据需要被接收，我们需要将这些报文做消散处理，避免短时间内再次通信时，收到了上次旧时报文。
- 如果第4次挥手时，ACK发送丢包，被动断开方会再次发送FIN数据，请求断开，这个时候如果，没有TIME_WAIT状态，那么被动断开方将无法收到ACK反馈（但是也没啥，如果发送一定次数后依旧没有ACK状态，被动接收方也就直接断开链接了）。
在TIME_WAIT下再次接收到FIN，将再次发送last ACK，然后重置TIME_WAIT时间重新等待
解决服务器TMIE_WAIT时需要紧急重启
在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的
- 服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户 端来请求).
- 这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产 生大量TIME_WAIT连接.
- 由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip, , 协议). 其中服务器的ip和端口和协议是固定的源端口 . 如果新来的客户端连接的 , 目的ip, 目的端口 ip和之前关闭的一样，会造成数据混乱。端口号和TIME_WAIT占用的链接重复了, 就会出现问题.
我们可以使用使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个 socket描述符.
int opt=1;
setsockopt(_listen_socket,SOL_SOCKET,SO_REUSEADDR|SO_REUSEPORT,&opt,sizeof opt);其实就是跳过判定端口是否被占用的代码。虽然可能数据混乱，但是比较服务器需要等待的损失会较小点。
)
