代做作业网站,写软文怎么接单子,网泰网站建设,通许网站建设先介绍我们UDP/TCP协议缓冲区
在UDP和TCP在数据传输和介绍时有有缓冲区概念的。
UDP缓冲区
UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后 续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序…先介绍我们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*460个字节也即是最大报文长度位60字节。但是一个tcp报文至少必须有标准报头20字节所以4位首部长度范围是5~15;
16位窗口大小 如果我们的client端一致给server发送报文但是我们的server端真正处理一个重要的报文也就是说发送速度和处理报文速率不相等导致了server端的接收缓冲区满了或者快满了这个信息必须通知发送方client。
servser当前缓冲区以使用980/1000server需要使用一种发送将当前链接的接收缓冲区情况通知clientserver将自己的接收缓冲区剩余情况发送给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发送的SYNACK证明了client的接收通路和发送通路畅通
server接收client发送的SYN后发送SYNACK进入等待后再次接收到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 opt1;
setsockopt(_listen_socket,SOL_SOCKET,SO_REUSEADDR|SO_REUSEPORT,opt,sizeof opt);
其实就是跳过判定端口是否被占用的代码。虽然可能数据混乱但是比较服务器需要等待的损失会较小点。
