关于门户网站建设,南京宣传片公司有哪些,大专网络营销专业好不好,网站导航还值得做目录
UDP协议
协议报头
UDP协议特点#xff1a;
应用场景#xff1a;
TCP
TCP协议报头
确认应答机制
理解可靠性
超时重传机制
连接管理机制 三次握手#xff1a;
四次挥手#xff1a;
滑动窗口
如何理解缓冲区和滑动窗口#xff1f;
倘若出现丢包#xf…目录
UDP协议
协议报头
UDP协议特点
应用场景
TCP
TCP协议报头
确认应答机制
理解可靠性
超时重传机制
连接管理机制 三次握手
四次挥手
滑动窗口
如何理解缓冲区和滑动窗口
倘若出现丢包怎么办
流量控制
拥塞控制
延迟应答
如何延迟应答
捎带应答 面向字节流
粘包问题
如何避免粘包问题
TCP的异常情况
查看网络状态的工具
应用场景
TCP总结 UDP和TCP协议都是传输层协议他们却大不相同。
UDP协议
协议报头 前四字节16位源端口号16位目的端口 次四字节16位UDP长度16位UDP校验和 16位源端口号16位目的端口表示报文的来源和报文要到哪去 16位UDP长度表示整个数据报(UDP首部UDP数据)的最大长度因为报头长度就是8字节所以至少是8。 16位UDP校验和用来校验数据发送端填写接收端进行校验如果校验和出错就会直接丢弃。 数据 即有效载荷 UDP协议特点 无连接知道对端的IP和端口号就直接发送数据不用建立连接。 不可靠即不能保证报文完整按序到达对端因为没有确认和重传机制。如果网络故障udp协议层也不会给应用层返回任何错误信息。倘若要实现可靠传输需要结合场景从TCP中选取策略在应用层实现策略。 面向数据报不能灵活控制读写数据都次数和数量发多少读多少udp不会拆分或合并报文socket支持全双工能在socket中同时读写即发送和接收独立虽然UDP无发送缓冲区调用sendto直接交给内核内核发送到对端但是UDP具有接收缓冲区但不能保证收到udp报的顺序和发送udp报的顺序一致 而且缓冲区满了再到达的数据被丢弃。 最大传输长度因为16位UDP报文长度字段所以最大传输长度2^1664K如果需要传输更多数据需要在应用层手动分包多次发送在接收端手动拼装 应用场景
应用对高速传输和实时性要求较高的通信领域
基于UDP的应用层协议 NFS: 网络文件系统 TFTP: 简单文件传输协议 DHCP: 动态主机配置协议 BOOTP: 启动协议(用于无盘设备启动) DNS: 域名解析协议 我们程序员写UDP程序时自定义的应用层协议 TCP
TCP协议报头 16位源端口16位目的端口表示报文从哪里来要到哪里去 32位序号TCP为了保证报文按序到达等将每个字节都进行了编号 32位确认序号用于确认序号之前的报文已经都发了 为什么有两组序号TCP是全双工的报文通常具有应答确认序号和发消息 序号 4位首部长度单位是4字节故至少是5表示TCP报头总长度至少为20字节 6个标记位 SYN请求建立链接的报文就标记为 1同步报文段 FIN 请求断开链接的报文就标记为 1结束报文段 ACK确认标记位表示对历史报文的确认 大部分情况是1 PSH数据推送标记位提示接收端应用程序立刻从TCP缓冲区把数据读走 URG紧急指针标记位表示数据需要被紧急处理需要忽略序号的处理顺序 RST 对方要求重新建立连接复位报文段 16位窗口大小表示TCP接收缓冲区所剩余的空间提示对端可以发送的数据长度最大值 为什么需要URG 报文发送可能乱序到达这是不可靠传输的一种情况TCP将收到的报文按序号排序以让报文按序到达但是有的报文优先级更高但序号更靠后 就无法做到数据被紧急处理为了表示该数据可以忽略序号可以被优先读取就标记该标记位。 16位校验和 16位紧急指针 校验和验证数据在网络传输中是否出问题 紧急指针以偏移量的方式在数据中找到紧急数据紧急数据主要用来获取服务器状态 确认应答机制
理解可靠性
什么是不可靠数据包丢包、数据包乱序到达、校验失败
如何确认报文丢包了只要得到应答就意味对方收到了 。 如何理解确认应答机制 TCP将每个字节的数据都进行了编号即为序列号整个报文首字节的编号就是32位序号。发送方发送报文给接收方接收方再发送携带ACK的报文每一个ACK都带有对应的确认序列号意思是确认序列号以前的报文都收到了也就是确认应答了。下次发送方发送的时候则报文的32位序号就从确认序号开始。倘若之前的报文没有被确认应答则会实行快重传或者超时重传机制来保证TCP的可靠性。
超时重传机制 超时重传顾名思义就是超过一段时间没有收到报文的确认应答消息就认为之前的报文丢失了于是就进行重新发送报文。因为要发送方收到接收方发送的报文确认之前的报文都收到了所以有之前发送的报文丢失了或接收方发送的确认接收的报文丢失了两种情况 显然在第二种情况下接收端就会收到重复的报文因为报头中有32位的序号字段所以可以根据序号进行去重将重复的报文丢弃掉。
如何确定超时的时间 这个时间太短就会导致发送重复的报文如果时间太长又会导致发送效率低下显然这个时间的长度收到网络环境的影响。最理想的情况下是找到一个最小的时间保证确认应答在这个时间内一定能收到为了保证在各种情况下都能具有高性能通信TCP将会动态计算这个时间。Linux中这个时间是以500ms为单位超时时间是500ms的整数倍。倘若重发一次还得不到应答则超时时间变为2*500ms倘若仍然得不到应答超时时间变为4*500ms进行重传以此类推按指数递增一定次数后TCP认为网络或对端主机出现异常强制关闭连接。 连接管理机制
在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接三次握手 起初客户端处于CLOSED状态服务端处于LISTEN状态客户端开始发送请求连接服务端的SYN报文然后进入SYN_SEND状态服务端接收到SYN报文后向客户端发送SYNACK报文然后进入SYN_RCVD状态客户端收到SYNACK报文后向服务端发送ACK报文并进入ESTABLISHED状态服务端收到ACK报文后进入ESTABLISHED状态至此三次握手过程完成。 注意当服务器进入listen状态的时候上层不调用accept接口也会建立链接这个链接将维护在内核的队列中这个对称的长度与listen第二个参数backlogn有关全连接队列长度参数n1表示在不accept的情况下最多维护链接数这说明底层建立好的链接是有上限的因为队列太长影响客户体验过于占用系统资源反而可能导致服务器效率低下这个全链接队列维护的意义在于可以让服务器在有闲置的情况下从底层获取链接进行链接处理是一种池化技术。 如图 为什么是三次握手不是两次或者一次 因为建立链接是需要花时间和空间也就是需要消耗服务端和客户端的系统资源的。倘若一次握手就建立链接那么如果有不法分子发送大量SYN请求也就是SYN泛洪攻击那么服务器资源很快就被榨干了如果是两次的话那也是服务端先进入ESTABLISED也状态就是收到SYN报文后就进入连接状态了那么和一次握手的道理也是一样的容易被SYN泛洪攻击导致服务器崩溃。倘若采用3次就可以让客户端先建立连接而服务器后建立链接后建立数据结构以最小成本的建立这样子相当于可以让SYN泛洪攻击的成本提高了相对更安全了。 四次挥手
如图 起初服务端与客户端都已经建立连接要求主动断开连接的一方可能是客户端也可能是服务端以客户端为例客户端主动断开连接向服务端发送FIN报文并进入FIN_WAIT_1状态服务端收到FIN报文后向客户端发送ACK报文服务端进入CLOSE_WAIT状态客户端收到ACK报文后进入FIN_WAIT_2状态服务端向客户端发送FIN报文并进入LAST_ACK状态客户端收到FIN报文后向服务端发送ACK报文并进入TIME_WAIT状态服务端收到ACK报文后进入CLOSED状态因为最后一个ACK报文是没有应答的所以报文可能丢失倘若经过两个MSLmaximum segment lifetime客户端没有回复FIN报文则客户端认为服务端已经收到了ACK报文不用超时重传了然后客户端进入CLOSED状态至此四次挥手完成。
因为中间两次报文都是由服务端往客户端一次性发送效率更高将FINACK报文发送给客户端也是可行的于是就变成了三次挥手这是一种特殊情况。 注意当被动关闭方进入CLOSED_WAIT状态后这个链接是一种半关闭状态是占有链接资源的当被动关闭方上层未调用close函数关闭套接字就会占用着系统资源。 当我们主动关闭服务器程序的时候服务器会自动进行四次挥手并且进入TIME_WAIT状态此时我们无法立即进行重启服务器需等待其进入CLOSED状态因为重启服务器会导致bind失败倘若非得这么干可以使用setsockopt接口第三个参数使用SO_REUSEADDR表示允许创建端口号相同但IP地址不同的多个socket描述符这样就可以绑定成功了。 TCP是面向连接的在进行通信之前服务器和客户端要建立连接建立连接的本质是OS要在底层维护相应的数据结构来管理连接而断开连接的本质则是释放底层维护的相应的数据结构所以对连接的管理具有时间和空间的成本。 滑动窗口 上面提到的应答机制TCP报文是一收一发的但是这样一收一发效率很低倘若一次发送多个报文就能大大提高效率本质是将多个报文的等待时间重叠在一起 但是一次多发存在可靠性问题因为其中报文可能丢包所以发送出去的数据在没有得到应答的情况下必须被保留以便支持超时重传。报文在发送端的发送缓冲区中保存发送缓冲区由已经发送并且确认应答的报文的区域已经发送但未得到响应结果的区域待发送区域组成 这个中间的区域被称为滑动窗口比如发送前4个报文不用等待ACK直接发送在收到第一个ACK之后滑动窗口右移继续发送第五个报文窗口的大小就是无需等待可以继续发送的数据的最大值这个大小与对方接收缓冲区剩余空间大小有关同时还与网络状况有关窗口越大则网络的吞吐率就越高。
如何理解缓冲区和滑动窗口
窗口本质就是内核用数据结构数组和两个头尾指针来进行描述的滑动的本质就是指针右移因为缓冲区大小有限这个数组是环形数组滑动窗口的大小是动态变化的。其中头指针以收到的最大的ACK序号右移尾指针则头指针窗口大小。
倘若出现丢包怎么办
数据包到达了但是ACK报文丢了可以通过后面的ACK报文确认 倘若数据包丢了当某一段报文丢了发送端会收到重复的ACK提醒发送端报文丢失当连续三次以上收到同样的报文后发送端就将相应的数据重新发送这个机制就是高速重发控制也称快重传。
流量控制
倘若发送端发送数据太快接收端的缓冲区被打满了这时再发送数据就会出现丢包等问题为了解决这个问题TCP报头有衡量自己接收缓冲区剩余空间大小的字段也就是窗口大小 自己的。所以发送端就能根据接收端的窗口大小来决定发送端的发送速度这个机制就是流量控制。 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 窗口大小 字段, 通过ACK报文通知发送端。 窗口大小字段越大表示网络的吞吐量越高。 接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知给发送端。 发送端接受到这个窗口之后就会减慢自己的发送速度。 如果接收端缓冲区满了就会将窗口置为0这时发送方不再发送数据但是需要定期发送一个窗口探测数据段使接收端把窗口大小告诉发送端 当然这个流量控制是双向的因为发送端和接收端在互相传输数据同时互相告知对方自己的窗口大小。
拥塞控制
当少量丢包的时候TCP会触发超时重传机制而倘若出现大量丢包则就应考虑网络的问题这时候的策略就不是立即重传数据包了因为会加重网络的负担不能马上超时重传TCP引入慢启动机制先发少量数据摸清当前网络拥塞状态再决定以多大的速度发送数据。
引入拥塞窗口
初始时拥塞窗口大小为1而后拥塞窗口大小为2,4,8...指数增长直到增长到慢启动阈值然后进行线性增长 第一次启动的时候TCP的慢启动阈值为窗口最大值第一次超时重发的时候慢启动阈值就变为原来的一半拥塞窗口变为1。这种指数增长的方式会使数据发送速度前期慢后期快所以前期都可以发少量数据探测网络状态而后期发送速度增长速度快可以尽快恢复网络通信。这是为了尽快把网络数据传输给对方又要避免给网络太大压力的折中方案。
前面提到滑动窗口大小就是一次给对方主机发送的数据量现在考虑到网络状况
一次向目标主机发送的数据量min(对方接收能力,拥塞窗口
也即滑动窗口大小min(对方窗口大小拥塞窗口大小
延迟应答 倘若接收数据的主机在收到数据的时间就立即返回ACK应答这时可能返回的窗口可能较小但是倘若等一会接收端很快就把数据处理掉了这时再返回ACK应答返回的窗口大小就更大窗口越大则网络的吞吐量越大传输效率越高这个策略就是延迟应答。
如何延迟应答
数量限制每隔N个包就应答一次。N常取2
时间限制超过最大延时时间就应答一次。一般延时时间取200ms 捎带应答
前面提到一收一发效率低如果在应答ACK的时候同时发送数据就可以提高效率这个策略就是捎带应答 面向字节流 TCP创建套接字的时候会在内核中创建发送和接收缓冲区调用write会现将数据写入发送缓冲区如果发送的字节数太长报文会被拆分成多个报文倘若发送的字节数太少就现在缓冲区等待等到缓冲区长度差不多或其他合适的时机再发送出去。 接收数据的时候数据从网卡程序到达内核的缓冲区然后应用程序调用read从接收缓冲区拿数据。因为发送端和接收端有两套缓冲区所以对于TCP连接既可以读数据也可以写数据这个概念叫做全双工 因为有缓冲区的存在所以TCP报文读写时不用匹配可以一次性调用一次read一次读取100个字节也可以分100一次调用每次读取1个字节。写入的时候也同理这种不用关心数据格式的读写特点就叫做面向字节流。 注意不关心数据格式意味着应用层需要处理。 粘包问题
上面提到TCP是面向字节流的也就是读取的时候可能读到一个半的报文这种情况这种情况被称为粘包问题这个包指的是应用层的包因为对于传输层而言报文字段中有序号报文是一个个抵达的而在应用层则是连续的字节数据。
如何避免粘包问题 即明确报文和报文的边界比如http协议中读取到空行认为报头读取完毕。 对于定长的包直接每次按固定长度读取即可 对于变长的包在报头定义报文长度的字段或者使用分隔符作为报文之间的边界 注意UDP不存在此问题UDP报文字段有报文长度且报文是一个个交给应用层的不能交付半个报文给上次UDP是面向数据报的 TCP的异常情况
1.进程终止时OS会自动四次挥手自动释放文件描述符和正常关闭一样
2.机器重启同进程终止本质也是终止进程
3.机器掉电、网线断开客户端掉线了断开网络了自然无法进行四次挥手而服务端认为还在再写入时发现连接不在会reset而且TCP内置了保活计时器会定期询问对方是否存在
查看网络状态的工具
netstat
选项 n 表示拒绝显示别名能显示数字的都转化成数字 l 尽列出listen状态的服务 t 仅显示tcp相关 p显示链接相关的程序名 高权限启动的程序需要提高权限才能看到 u仅显示udp相关 应用场景
应用于需要可靠传输的场景比如文件传输重要文件更新等场景
基于TCP应用层协议 HTTP超文本传输 HTTPS超文本传输安全协议 SSH安全外壳协议 Telnet远程登录协议 FTP文件传输协议 SMTP简单邮件传输协议 TCP总结
为什么TCP这么复杂? 因为要保证可靠性同时又尽可能的提高性能。如何保证可靠性1.报文中有校验和字段 2.报文中有序列号字段(可以确保报文按序到达) 3.确认应答报文中有确认序号和ACK字段表示收到了报文 4.超时重发倘若丢包一定时间段后会进行超时重传 5.连接管理建立连接数要进行三次握手断开连接时要进行四次挥手 6.流量控制使用滑动窗口根据接收方窗口大小来决定发送方的发送速度 7.拥塞控制大量丢包认为网络状况出问题引入拥塞窗口和慢启动机制来解决 提高性能: 1.滑动窗口min拥塞窗口大小接收方窗口大小尽可能一次多发数据 2.快速重传连续收到3个以上相同确认序号的ACK报文就进行重传 3.延迟应答接收数据后稍作等待尽可能让上层获取更多的数据提高剩余接收窗口大小 4.捎带应答在发送数据的时候让ACK搭顺风车顺便对以前收到的数据进行确认 其他: 定时器超时重传定时器 保活定时器维持连接 TIME_WAIT定时器
