商洛网站建设求职简历,asp连接数据库做登录网站完整下载,什么是响应式设计,长沙网站开发那家好前面了解到服务器和客户端在创建套接字#xff0c;建立连接后#xff0c;就可以进入到下一步#xff0c;双发可以互相发送和接收数据#xff0c;本篇博客就来学习一下这个过程。 我们印象里#xff0c;发送数据应该是我们在浏览器输入网址#xff0c;敲击回车的一瞬间建立连接后就可以进入到下一步双发可以互相发送和接收数据本篇博客就来学习一下这个过程。 我们印象里发送数据应该是我们在浏览器输入网址敲击回车的一瞬间发送动作就完成了回头服务器处理完成将数据发送客户端浏览器解析出来这就是反过来接收的过程。
1. 发送数据 由浅入深了解这个大体过程我们先来看看发送数据的简单过程。对于浏览器他没有办法直接向网络中发送数据而是要将http请求委托给协议栈操作系统的网络控制软件来发送。但实际上在计算机中并不是只有浏览器会发送网络请求QQ、微信等很多应用程序都会执行这个动作。所以协议栈工作就是会接收各种应用程序发送过来的网络请求数据其实就是一堆的二进制字节数据。 协议栈在拿到数据后是不是会直接发送到网络中的呢必然不是他在内部会维护一段内存缓冲区等待下一段数据然后在某个合适的时机再发送出去。这块内存就是发送数据的专用缓冲区。当然接收数据的时候也是有一块专用内存的后面我们再说这个。这里还提到了合适的时机发送数据这个时机是根据两个要素来判断的我们看看是哪两个。
1.1 网络包长度 第一个因素是跟网络包长度相关的什么意思呢对于某些GET请求要发送的请求内容必然很少一个网络包就能放得下但是有些POST请求比如我要写的这篇博客经过编码解析需要很多歌网络包才能放的下这里就涉及到拆包的概念。 这里先了解两个网络词汇MTUMSS
MTU 指的是一个网络包的最大长度以太网中通常是1500个字节。MSS MTU中去掉头部之后所能容纳的数据的最大长度。 了解这两个概念我们在来看下上面说的拆包的概念即我们发送的某次网络请求可能是通过1个网络包发送给服务器的也可能是很多个决定因素就是MTU和MSS。 在应用程序将数据发送给协议栈的时候数据可大可小协议栈无法决定如果每次接收到应用程序的一次数据就立即发送出去必然会导致发送大量小的网络包网络效率下降。所以协议栈一般会累积到数据量可以塞满一个网络包的时候再发送出去即MTU的长度这就是第一个决定协议栈发送数据的因素。
1.2 发送时间 决定协议栈 发送数据的第二个因素是时间为啥呢我们可以试想一下如果GET请求的数据长度无法达到一个MTU的长度协议栈一直等待到一个网络包的数据长度再发出去必然会产生很大的延迟给我们卡顿的感觉。所以某些情况下即便网络包没有被填满也会立即把数据发送出去。 协议栈内部会维护一个计时器在超过设定的时间阈值后即便没有达到一个完整网络包数据长度也会立即发送。一般这个时间是由协议栈的开发者决定的不同操作系统的不同版本会有不同实现。 其实决定协议栈发送数据的这两个要素在某些情况下是比较矛盾的立即发送会导致网络效率下降等待太久又会造成延迟。过分依靠协议栈来决定发送时机会带来一些问题所以协议栈也给了应用程序一个选项来决定是否立即发送。像浏览器这样的会话型应用程序一般会选择“立即发送”的选项。
2. 确认发送成功以及重发功能的实现 TCP协议的非常重要的功能就是可以确认通信的一方是否已经成功收到了网络包如果没有收到必须具有重发的功能。这个功能的实现就是借助于ACK号和seq序号要进行对方接收确认的操作。 上文我们说过在网络请求内容过大的时候TCP会有拆包的逻辑那么在拆分的过程中TCP就会计算好并记录每个网络小包在整个请求内容中处于第几个字节然后再发送网络包的时候在TCP头部记录这个字节数就是seq序号比如目前是第1个字节服务器在接收到网络包的时候会读取这个字节然后再计算这个网络包MSS的长度比如网络包数据长度是1000在确认回复的时候会将ACK赋值为ACK 1 1000 并返回给客户端。客户端在接收到ACK号的时候就可以确定网络包已经顺利被对方接收否则就会重试发送。 我们可以想象一下客户端在发送下一个网络包的时候一定是从第1001个字节开始的于是服务器在收到请求后可以顺便验证1001是不是和自己最后一次ACK响应的字节数相等如果相等说明中间没有丢包如果是2001说明中间丢失了至少一个网络包。 这里我们已经提到了ACK和seqTCP协议可以通过ACK号和序号就可以确认对方是否收到了网络包。我们来看一个虚拟的例子加深一下了解。 2.1 调整ACK号等待时间 我们的网络传输并不是一帆风顺的发生拥塞和抖动的情况是非常常见的。前文我们提到TCP会通过ACK号确认对方已经接收到网络包但是在网络比较慢的情况下发送和接收ACK号的平均响应时间就会比较长了如果客户端在这个时候设置了比较短的等待时间就会在没收到ACK的情况一直向以太网中发送数据这对于本来已经繁忙的网络就更加糟糕了这其实就是TCP的网络包重传。 通常当网络包重传发生后有可能前一个相同网络包的ACK号才返回这样的重传其实是不必要的。所以对于等待时间来说需要设置一个合适的值这个时间应该是可以动态调整的而计算方法就是根据过往发送数据的过程中持续监测ACK号的响应时间如果ACK号的返回时间变慢就会响应延长这个等待时间否则就缩短等待时间。 除此之外TCP还是使用了滑动窗口的方式来管理数据发送和ACK号的管理大体思路就是第一个网络包在发送出去之后并不是等待当前网络包的ACK号返回才发送下一个而是直接发送下一个或者说是下面一系列的网络包这样的话发送的等待时间就会被有效的利用起来了。这个过程相对复杂一些涉及到窗口大小的概念这个窗口大小就是指接收方网络协议栈中在当前时间里剩余的最大缓存空间也就是能接收的字节数。下图中可以看出来一来一回和滑动窗口的方式这里不再深入展开可以查看相关资料。 3. 接收数据 在客户端发送完数据的过程后服务器端就可以接收并处理网络包了对于单个网络包的处理比较简单对于客户端拆分后分多次发送的网络包服务器的TCP协议同样会以相同的方式拼接起来转换成为对应的网络请求其实就是和客户端处理相反的方式进行的。服务器在处理请求后就会将相应数据发送给客户端。 我们可以想一下客户端的浏览器程序在委托协议栈发送了网络请求后就处于等待响应结果的状态。这个状态其实是浏览器调用了Socket组件库的read()函数协议栈会将这个工作挂起直到服务器数据相应之后协议栈写入到接收缓冲区中在这个过程之前接收缓冲区一直是空的浏览器就无法处理数据这个挂起就是我们常说的阻塞过程。这个如果继续延伸的话会有阻塞式IO非阻塞式IOIO多路复用等知识点在此不深入。 总结一下这个过程客户端的协议栈会检查接收到的数据和TCP头部的内容判断是否有数据丢失如果没有问题会向服务器返回ACK号。然后协议栈将接收到的数据暂存到接收缓冲区这个缓冲区是协议栈的中然后将数据块按照顺序连接起来还原成原始的数据最后将数据交还给应用程序其实是把协议栈缓冲区中的数据复制到浏览器制定的内存地址中然后浏览器去解析的过程这个过程还是在read里面实现并把控制流程交还给浏览器的。
4. 断开连接 接下来最后一个流程就是数据发送完成之后的断开连接了那么断开连接这个操作是由客户端还是服务端发起的呢 在协议栈中并没有规定哪一方应该先发起断开操作通常是由应用程序判断自己的数据已经发起后就可以发起断开动作了。比如我们访问web服务器发送请求服务器接受请求处理完成会向客户端返回数据包等到所有数据都返回了服务器会主动发起断开操作。下面我们就以这个例子服务器先发起断开操作理解这个过程。 所谓的断开操作也是由发起方调用Socket库的中close()程序实现的在这个方法中协议栈会生成包含了断开控制信息的TCP头部具体来说就是将FIN比特位设置1然后再委托IP模块将数据发给客户端接下来服务器套接字中就会记录下断开操作的相关信息。 接下来看我们的客户端在接收到FIN比特位为1的包时客户端知道了噢服务器要断开连接了那好在自己的套接字中标记一下要进入断开操作了记住这里只是标记一下同时必须要返回服务器ACK号告知服务器已收到FIN1的断开网络包了。 然后待到客户端协议栈接收缓冲区数据被应用程序全部取走之后(前面讲到的应用程序的read()操作)客户端感觉时机成熟了也会向服务器发送一个包含FIN1头部的网络包服务器同理也要返回ACK包至此双方的通讯正式结束。 5. 删除套接字 接下来断开操作的最后一步就是删除套接字这里尤其注意用来通讯的套接字不会立即删除而是会等待一段时间后再删除具体原因如下 我们现在举个跟上面相反的断开的例子由客户端发起断开请求
客户端发送FIN1包服务器返回ACK号服务器发送FIN1包客户端返回ACK号 这里特别注意最后一步客户端在返回ACK号之后如果立即删除套接字会发生什么呢正常情况可能是服务器收到客户端的ACK号双方通讯结束没问题。但是如果因为网络拥塞问题服务器没有在规定时间收到第四步的ACK号那么服务器又发送了一次FIN1这里可能会有问题了因为客户端已经删除了套接字此时如果恰巧又其他应用程序请求连接服务器并且创建了相同端口号的套接字那么这个新创建的套接字因为收到了一条莫名奇妙的FIN1就要进入断开操作了就会有问题了。所以客户端并不会立即删除套接字就是为了防止这个问题发生。 通常这个等待删除套接字的时间就是几分钟而已。
6. TCP的整体流程
