网建网站,重庆网站推广系统,营销型网站页面,福州seo公司技术文章目录 1. UDP1.1 UDP结构1.2 UDP特点1. 无连接2. 不可靠3. 面向数据报4. 缓冲区5. 大小受限6. 无序性 2. TCP2.1 TCP结构2.2 TCP特点1. 有连接2. 可靠性3. 面向字节流4. 拥塞控制5. 头部开销 2.3 TCP原理1. 确认应答#xff08;安全机制#xff09;2. 超时重传#xff08… 文章目录 1. UDP1.1 UDP结构1.2 UDP特点1. 无连接2. 不可靠3. 面向数据报4. 缓冲区5. 大小受限6. 无序性 2. TCP2.1 TCP结构2.2 TCP特点1. 有连接2. 可靠性3. 面向字节流4. 拥塞控制5. 头部开销 2.3 TCP原理1. 确认应答安全机制2. 超时重传安全机制3. 连接管理安全机制4. 滑动窗口效率机制5. 流量控制安全机制6. 拥塞控制安全机制7. 延迟应答效率机制8. 捎带应答效率机制 2.4 粘包问题 1. UDP
1.1 UDP结构 2字节的长度表示整个数据报的最大长度UDP首部UDP数据。校验和用来验证数据是否出错出错就摒弃。首部8个字节。源/目的端口号表示数据是从哪个进程来到哪个进程去校验和发送端填充CRC校验。接收端校验不通过则认为数据有问题。 1.2 UDP特点
1. 无连接 知道对方的端口和IP就可以直接传输不用建立连接。 这使UDP更加的轻量级适用于一些实时性高的应用。 2. 不可靠 UDP没有任何安全机制发送端发送数据报以后如果因为网络错误发生错误UDP协议层也不会给应用层返回任何错误信息。 3. 面向数据报 应用层给UDP多长的报文就会发送多长的报文并不会拆分合并。 4. 缓冲区 UDP并没有真正的发送缓冲区具有接受缓冲区。 UDP的scoket既能读又能写所以是全双工。 5. 大小受限 UDP协议首部有个16位的最大长度所以一次最多传输64Kb包括UDP首部。 6. 无序性 UDP不保证数据包的传输顺序这对某些应用来说可能是一个缺点但对其他应用来说这样的特性可以提高性能。 2. TCP
2.1 TCP结构 6位标志位: URG紧急指针是否有效 ACK确认号是否有效 PSH提示接收端应用程序立刻从TCP缓冲区把数据读走 RST对方要求重新建立连接我们把携带RST标识的称为复位报文段 SYN请求建立连接我们把携带SYN标识的称为同步报文段 FIN通知对方本端要关闭了我们称携带FIN标识的为结束报文段。 2.2 TCP特点
1. 有连接 通信双方通信前需要建立连接知道对方的端口号和IP。 2. 可靠性 TCP提供可靠的数据传输确保数据的完整性和顺序。主要通过确认应答。 3. 面向字节流 TCP是面向字节流的协议而不是面向消息的。这意味着应用程序需要负责将数据分割为适当的消息或数据块以便进行传输。 4. 拥塞控制 TCP拥有拥塞控制机制它可以调整发送速率以避免网络拥塞。通过监控网络的延迟和丢包情况TCP可以自动适应不同的网络条件。 5. 头部开销 TCP头部较大包含序号、确认号、窗口大小等字段因此在某些情况下可能引入较高的开销。 2.3 TCP原理 TCP相对UDP安全性提高但是效率却降低了所以TCP中引入了很多在保证安全的情况下提高传输效率。 1. 确认应答安全机制 TCP将每个字节的数据都进行了编号即为序列号。每一个ACK都带有对应的确认序列号意思是告诉发送者我已经收到了哪些数据下一次你从哪里开始发。 确认应答就是对方收到消息后给出回应让对方知道你收到了。 每当一方收到数据包时它会发送一个确认应答通常包含了已经成功接收的数据的序号。这确保了数据的可靠传输因为发送方会等待确认应答以确定数据已经到达并且没有丢失。 2. 超时重传安全机制 当对方的回应你迟迟没有收到当到达一定时间可以重新发送一次。 当一方的数据包或者对方的确认应答在传输途中丢失一定时间后会重新发送相同的数据包直到收到确认应答。累计到一定的重传次数TCP认为网络或者对端主机出现异常强制关闭连接。 3. 连接管理安全机制 正常情况下TCP要经过三次握手建立连接四次挥手断开连接。 三次握手 第一次握手客户端向服务器发送一个特殊的TCP报文这个报文中的SYN标志位被置为1这个报文表示客户端希望建立连接。 第二次握手服务器收到客户端的SYN报文后需要确认建立连接。服务器会响应一个包含SYN和ACK标志位的报文。这个报文表示服务器同意建立连接。 第三次握手客户端收到服务器的确认后也要发送一个确认报文ACK。这个报文告诉服务器它已经收到了服务器的确认连接建立完成。 四次挥手 第一次挥手关闭方通常是客户端向另一方发送一个TCP报文带有FIN标志位表示它已经没有数据要发送但仍愿意接收数据。这个报文开始了连接的关闭过程。 第二次挥手接收方收到第一次挥手的报文后它会发送一个ACK确认报文作为响应。表示接收方已经收到并确认了关闭方的FIN报文。 第三次挥手接收方通常是服务器在确定没有更多数据要发送后也会发送一个FIN标志的报文通知对方它准备关闭连接。 第四次挥手关闭方收到第三次挥手的报文后也要发送一个ACK确认报文作为响应以确认接收方的关闭请求。 4. 滑动窗口效率机制 上述传输数据时每次发送一个数据都需要等待ACK才能发送下一段数据这样的效率并不高性能较差所以引入了滑动窗口。 如图 我们可以一次发送多条数据这样就能才等待时间重叠在一起提高性能。 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节四个段。 发送前四个段的时候不需要等待任何ACK直接发送 收到第一个ACK后滑动窗口向后移动继续发送第五个段的数据依次类推 操作系统内核为了维护这个滑动窗口需要开辟发送缓冲区来记录当前还有哪些数据没有应答只有确认应答过的数据才能从缓冲区删掉 窗口越大则网络的吞吐率就越高 丢包处理 丢了ACK 这种情况下如果前面的部分ACK丢失只要接受到后面的ACK依然可以确认应答。 丢了数据包 当某一段报文段丢失之后发送端会一直收到 1001 这样的ACK就像是在提醒发送端 “我想要的是 1001” 一样 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答就会将对应的数据 1001 - 2000 重新发送 这个时候接收端收到了 1001 之后再次返回的ACK就是7001了因为2001 - 7000接收端其实之前就已经收到了被放到了接收端操作系统内核的接收缓冲区中 这种机制被称为 “高速重发控制”也叫 “快重传”。 5. 流量控制安全机制 接收端处理数据的速度是有限的。如果发送端发的太快导致接收端的缓冲区被打满这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力来决定发送端的发送速度。这个机制就叫做流量控制。 TCP通过流量控制机制来管理数据传输以确保发送方不会发送过多的数据从而导致接收方无法处理或网络拥塞。流量控制的主要目标是防止数据包的丢失和网络拥塞。以下是TCP流量控制的关键概念和工作原理 窗口机制TCP使用窗口机制来进行流量控制。接收方会告诉发送方它可以接收多少数据这个信息被称为接收窗口大小Receiver Window Size。 滑动窗口发送方维护一个发送窗口它表示当前可以发送的数据量。这个窗口的大小受到接收方的接收窗口大小和网络条件的影响。 通告窗口大小接收方会在TCP报文中通告当前的接收窗口大小发送给发送方。这告诉发送方可以发送多少数据以避免过载接收方。 动态调整窗口大小接收方可以根据自身处理能力和可用内存动态调整接收窗口大小。如果接收方无法及时处理数据它可以减小窗口大小通知发送方降低发送速率。 流量控制的目的流量控制的主要目的是防止发送方发送过多数据从而导致接收方缓冲区溢出数据丢失或网络拥塞。通过维护适当的接收窗口大小TCP可以确保发送和接收之间的数据传输协调顺畅。 自适应机制TCP的流量控制是自适应的它可以根据网络状况进行调整。如果网络拥塞接收方可以减小窗口大小发送方会相应降低发送速率从而减轻网络负担。 6. 拥塞控制安全机制 虽然TCP有了滑动窗口这个大杀器能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据仍然可能引发问题。 因为网络上有很多的计算机可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下贸然发送大量的数据是很有可能引起雪上加霜的。 TCP引入慢启动机制先发少量的数据探探路摸清当前的网络拥堵状态再决定按照多大的速度传输数据 7. 延迟应答效率机制 如果接收数据的主机立刻返回ACK应答这时候返回的窗口可能比较小。一定要记得窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率 规则 数量限制每隔N个包就应答一次 时间限制超过最大延迟时间就应答一次 具体的数量和超时时间依操作系统不同也有差异一般N取2超时时间取200ms 8. 捎带应答效率机制 在延迟应答的基础上我们发现很多情况下客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”服务器也会给客户端回一个 “Fine, thank you” 那么这个时候ACK就可以搭顺风车和服务器回应的 “Finethank you” 一起回给客户端 2.4 粘包问题 首先要明确粘包问题中的 “包” 是指的应用层的数据包。 在TCP的协议头中没有如同UDP一样的 “报文长度” 这样的字段但是有一个序号这样的字段。 站在传输层的角度TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。 站在应用层的角度看到的只是一串连续的字节数据。 那么应用程序看到了这么一连串的字节数据就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包。 那么如何避免粘包问题呢归根结底就是一句话明确两个包之间的边界。 对于定长的包保证每次都按固定大小读取即可例如上面的Request结构是固定大小的那么就从缓冲区从头开始按sizeofRequest依次读取即可对于变长的包可以在包头的位置约定一个包总长度的字段从而就知道了包的结束位置对于变长的包还可以在包和包之间使用明确的分隔符应用层协议是程序猿自己来定的只要保证分隔符不和正文冲突即可 对于UDP协议来说是否也存在 “粘包问题” 呢 对于UDP如果还没有上层交付数据UDP的报文长度仍然在。同时UDP是一个一个把数据交付给应用层。就有很明确的数据边界。 站在应用层的站在应用层的角度使用UDP的时候要么收到完整的UDP报文要么不收。不会出现半个的情况。
