济宁市工程建设职业学校网站,网站开发的账务处理,html网页设计基础,设计优秀的网站推荐一. UDP协议
UDP协议端格式 由上图可以看出#xff0c;一个UDP报文最大长度就是65535. • 16位长度#xff0c;表示整个数据报#xff08;UDP首部UDP数据#xff09;的最大长度#xff08;注意#xff0c;这里的16位UDP长度只是一个标识这个数据报长度的字段#xff0…一. UDP协议
UDP协议端格式 由上图可以看出一个UDP报文最大长度就是65535. • 16位长度表示整个数据报UDP首部UDP数据的最大长度注意这里的16位UDP长度只是一个标识这个数据报长度的字段并不是这个数据报传输的数据 • 如果校验和出错就会直接丢弃。 校验和通过网线传输时电信号使用高低电平来表示0和1.。但是如果外部环境干扰就有可能导致低电平-高电平高电平-低电平造成比特翻转数据就传输错了。校验和就是通过数据报中的数据内容通过计算得到的。值得注意的是如果校验和不对此时你的数据一定不对如果校验和对但是数据也有一定概率是错误的。
面向数据报应用层交给UDP长的报文UDP原样发送既不会拆分也不会合并。
用UDP传输100个字节的数据报 如果一次发送端发送100个字节那么接收端也必须一次接收100个字节而不能循环10次接收每次接收10个字节。 缓冲区UDP只有接收缓冲区没有发送缓冲区 UDP没有真正意义上的发送缓冲区发送的数据会直接交给内核由内核将数据传给网络层协议进行后续的传输动作 DUP具有接收缓冲区但是这个接收缓冲区不能保证收到的DUP报的顺序和发送DUP报的顺序一致如果缓冲区满了再到达的DUP数据就会被丢弃 二. TCP协议
TCP协议段格式 2.1 TCP原理
2.1.1 确认应答机制 TCP 将每个字节的数据都进行了编号。即位序列号。 发送方的序号为最后一个字节的编号确认序号为无意义的数据
接收方的序号和发送方的序号无关确认序号为接收数据的序号1。
在接收缓冲区中优先级队列通过序号来确定数据的发送先后顺序
接收方就可以通过ack的确认序号告诉发送方哪些数据已经收到了。
2.1.2 超时重传机制
主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会重发。 但是主机A未收到B发来的确认应答也可能是因为主机B收到了数据但是ACK丢失了 因此若ACK丢失了主机B会收到很多重复数据。那么TCP协议需要能够识别哪些包是重复的包并且把重复的丢弃掉。这时候我们就可以利用前面提到的序号来达到去重的效果。 超时重传后重复发送的数据报仍可能会丢失TCP为了保证无论在任何环境下都能比较高性能的通信因此会动态的计算这个最大超时时间。 如果重发一次仍得不到应答TCP就会将这个超时时间延长后再重发在不停的延长超时时间后当累积到一定的重传次数后,TCP就会重置连接如果重置连接失效TCP就会关闭连接放弃网络通信。 2.1.3 连接管理机制三次握手四次挥手
建立连接三次握手
握手指的是通信双发进行一次网络交互相当于客户端和服务器之间通过三次交互建立了连接关系。 syn称为同步报文段。意思就是一方要向另一方申请连接。 在报文头部中有6个特殊的比特位如果设为1则表示特定含义。 其中第二位是ACK如果这一位为1表示当前TCP数据报是一个应答报文 其中第五位是SYN如果这一位为1表示当前TCP数据报是一个同步报文 如果一个TCP数据报第二位和第五位都是1则当前这个报文时SYNACK 三次握手这个过程本质上时投石问路验证了客户端和服务器各自的发送能力和接收能力是否正常
断开连接四次挥手
FIN结束报文段 四次挥手中的ack和fin是否可以合并 在三次握手中ack和syn时同一时刻触发的都是内核来完成的 四次挥手ack和fin则是在不同时机触发的。 ack是内核完成的会在收到fin的时候第一时间返回 fin则是应用程序代码控制的。在调用到socket的close方法时候才会出发fin finally{ //thread.sleep(1000);socket.close();
} 这个close的执行时机可能是立即也可能是隔很久却决于你的代码怎么写。 如果立即 close趁着刚才ack还没发呢这里就可以合并如果是隔很久再close此时fin就只能单独发了。 注这里的close只是进程关闭了但是连接连接是内核维护的还在客户端发送的ack服务器仍然可以收到。
2.1.4 滑动窗口(效率机制)
对于每一个发送的数据段,都要给一个ACK确认应答,收到ACK后再发送下一个数据段。.由于这样的一收一发的方式性能较低那么我们一次发送多条数据就可以大大的提高性能。其实是将多个段的等待时间重叠在一起了。 • 窗口大小指的是无需等待应答而可以继续发送数据的最大值.上图的窗口大小就是4000个字节(4个段)。 • 发送前四个段的时候不需要等待任何ACK直接发送。 • 操作系统内核为了维护这个滑动窗口需要开辟发送缓冲区来记录当前还有哪些数据没有应答只有确认应答过的数据才能从缓冲区删掉。 • 窗口越大则网络的吞吐率就越高。 如果出现了丢包的情况如何重传分两种情况
情况一数据包已经抵达ACK被丢了。 这种情况下部分ACK丢了并不要紧因为可以通过后续的ACK进行确认。如果1001的 ACK没有接收到收到了2001的ACK那么就说明已经接收到了2001以前的数据。
情况二数据包直接丢了。 • 当某一段报文丢失之后发送端会一直收到1001这样的ACK就像是在提醒发送端“我想要的是1001一样 • 当发送端主机连续收到三次同样的“1001”这样的应答就会将对应的数据1001~2000重新发送 • 这个时候接收端收到了1001之后再次返回的ACK就是7001了因为2001~7000接收端其实之前就已经收到了被放到了接收端操作系统内核的接收缓冲区中。 2.1.5 流量控制安全机制
接收端处理数据的速度是有限的。如果发送端发送的太快导致接收端的缓冲区被打满这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等一些列连锁反应。
因此TCP支持根据接收端的处理能力来决定发送端的发送速度。这个机制就叫做流量控制 • 接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段通过ACK端通知发送端此时发送端就可以根据这个窗口大小来批量发送这些数据了。 • 接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知给发送端 • 发送端接收到了这个窗口之后就会减慢自己的发送速度 • 如果接收端缓冲区满了就会将窗口设置为0这时发送方就不再发送数据但是仍需要定期发送一个窗口探测数据段使接收端把窗口大小告诉发送端。 上述过程是把返回的窗口大小当作实际的窗口实践中可能会有出入。
发送方的窗口大小min(流量控制,拥塞控制)。
2.1.6 拥塞控制安全机制
虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据.但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题.
因为网络上有很多的计算机,在传输的过程中,需要经历许多的节点,可能当前的网络状态就已经比较拥堵了,但是此时在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的.于是,不管在客户端与服务器之间是经历怎样的路径,把这个路径当做黑盒一样的东西,每次发送不同数量的请求,来试验出最佳的发送窗口. TCP引入 慢启动 机制,先发送少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据 • 发送开始的时候,定义拥塞窗口大小为1 • 每次收到一个ACK应答,拥塞窗口加1 • 每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小作比较,取较小的值作为实际发送的窗口 为了让拥塞窗口不增长的那么快,变引入了一个叫做慢启动的阈值,当拥塞窗口超过这个阈值的时候,不再按照指数的方式增长,而是按照线性方式增长 • 当TCP开始启动的时候,慢启动阈值等于窗口最大值; • 在每次超时重发的时候,慢启动阈值会变成原来的一般,同时拥塞窗口重置回1. 2.1.7 延迟应答
如果接受数据的主机立刻返回ACK应答,这时候返回的窗口肯能比较小. • 假设接收缓冲区为1M,一次收到了500k的数据,如果立刻应答,返回的窗口就是500k • 但实际上可能处理端处理的速度很快,10ms之内就把500k的数据从缓冲区消费掉了 • 在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来 • 如果接受端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M 窗口越大,网络吞吐量就越大,传输效率就越高.我们的目标是在保证网络不拥塞的情况下尽量提高传输效率.
但是并不是所有的包都可以延迟应答 • 数量限制:每隔N个包就应答一次; • 时间限制:超过最大延迟时间就应答一次 具体的数量和超时时间,操作系统不同也有差异;一般N取2,超时时间取200ms(根据业务需求可自定义)
2.1.8 捎带应答
在延迟应答的基础上,我们可以发现,很多情况下,客户端服务器在应用层也是一发一收的.意味着客户端给服务器说了How are you , 服务器中程序处理过请求后也会给客户端返回一个Fine,thank you , 那么这个时候ACK就可以搭顺风车,和服务器回应的Fine, thank you 一起返回给客户端 上述ACK是内核收到数据报后直接返回的,Fine....是应用程序,通过write写的数据,通过一系列代码执行到才返回,这俩时机本来是不同的.但是延时应答,使此时的ACK 就可能稍等一会再发送就很有可能和response 合并成一个数据报.四次挥手,有可能是三次挥手,就是捎带应答起到的效果.
2.2 粘包问题
在TCP协议头中没有如同UDP一样的“报文长度”这样的字段但是有一个序号这样的字段站在传输层的角度TCP是一个一个报文过来的。按照序号放在缓冲区中。站在应用层的角度看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据就不知道从哪个部分开始到哪个部分结束是一个完整的数据包。
如何解决粘包问题归根结底就是一句话明确两个包之间的边界。 • 对于定长的包保证每次都按照固定大小读取即可例如上面的Request结构是固定大小的那么就从缓冲区从头开始按sizeof(Request) 依次读取即可 • 对于变长的包可以定义分隔符来区分包应用层协议是程序员自己来定的只要定义保证分隔符不和正文冲突即可 • 对于变长的包还可以在包头的位置约定一个包总长读的字段从而知道了包的结束位置 对于UDP协议来说是否也存在“粘包问题” • 对于UDP如果还没有上层交付数据UDP的报文长度仍然在。同时UDP是一个一个把数据交付给应用层。就有很明确的数据边界。 • 站在应用层的角度使用DUP的时候要么收到完整的UDP报文要么不收不会出现“半个”的情况。 2.3 TCP异常情况
2.3.1 进程关闭/进程崩溃
进程没了socket 是文件随之被关闭虽然进程没了但是连接还在仍然可以继续四次挥手
2.3.2 主机关机正常流程关机
先杀死所有的用户进程然后就和进程关闭一样。
虽然可以出发四次挥手如果能够在关闭之前完成更好。
如果没有发完比如对方发的 fin 过来了咱们没来得及ack就关机了此时对端就会重传fin,重传几次之后发现都没有ack,尝试重置连接如果还不行就直接释放连接。
2.3.3 主机掉电把电源
瞬间机器就关了来不及进行任何挥手操作。此时分两种情况
1对端是发送端
对端就会收不到ack超时重传重置连接释放连接
2对端是接收端
对端是没法立即知道你这边是还没来得及发新的数据还是直接没了。即使发送端没有写入操作TCP自己也内置了一个保活机制“心跳包”。虽然是接收端但是接收端会定期给发送端发送一个心跳包ping),正常情况下就会返回一个(pong)如果每个 ping 都有及时的 pong这个时候就说明当前对端的状态良好如果 ping 过去之后没用 pong 说明心跳没了这边怕是打概率挂了pong也有概率丢的因此会连续几次都丢了才会判定连接断开。
注发送方也是有心跳包的但是通过对方返回的ack来判定会更快一些。
