网站地图网页的制作,外汇网站模版,做网站成功案例,怎样查看别人网站流量超时重传机制连接管理机制三次握手四次挥手滑动窗口拥塞控制延迟应答捎带应答面向字节流粘包问题TCP异常情况TCP小结基于TCP应用层协议理解 listen 的第二个参数 超时重传机制 主机A发送数据给B之后#xff0c;可能因为网络拥堵等原因#xff0c;数据无法到达主机B#xff1… 超时重传机制连接管理机制三次握手四次挥手滑动窗口拥塞控制延迟应答捎带应答面向字节流粘包问题TCP异常情况TCP小结基于TCP应用层协议理解 listen 的第二个参数 超时重传机制 主机A发送数据给B之后可能因为网络拥堵等原因数据无法到达主机B如果主机A在一个特定时间间隔内没有收到B发来的确认应答就会进行重发
发送方如何判定丢包了呢 其实真正有没有丢包发送方其实不知道。定的策略超时了就判定丢包了
但是主机A未收到B发来的确认应答也可能是因为ACK丢失了 因此主机B会收到很多重复数据这也是不可靠的一种那么TCP协议需要能够识别出那些包是重复的包并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号就可以很容易做到去重的效果
思考点发送端发出去数据被发出的数据并不想我们想的那样立马移除而是必须被维持一段时间维持在发送窗口或发送缓冲区
如果超时的时间如何确定?
最理想的情况下找到一个最小的时间保证 “确认应答一定能在这个时间内返回”。但是这个时间的长短随着网络环境的不同是有差异的。如果超时时间设的太长会影响整体的重传效率如果超时时间设的太短有可能会频繁发送重复的包
TCP为了保证无论在任何环境下都能比较高性能的通信因此会动态计算这个最大超时时间。
Linux中(BSD Unix和Windows也是如此)超时以500ms为一个单位进行控制每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后仍然得不到应答等待 2*500ms 后再进行重传。如果仍然得不到应答等待 4*500ms 进行重传依次类推以指数形式递增。累计到一定的重传次数TCP认为网络或者对端主机出现异常强制关闭连接
连接管理机制
在正常情况下TCP要经过三次握手建立连接四次挥手断开连接 三次握手 为什么要三次握手
一次握手只有一次握手那么连接的建立就无法得到确认无法确定双方的发送和接收能力也无法建立可靠的连接SYN洪水二次握手只有两次握手虽然可以确认一方的发送和接收能力但无法保证另一方的接收能力。这可能导致双方在不同的时间窗口内发送数据从而导致数据的不同步和丢失SYN洪水
为什么不四次握手
可靠性TCP 的三次握手已经足够确保连接的可靠性。通过三次握手客户端和服务器可以确保彼此的发送和接收能力正常并达到同步的状态。在第三次握手中服务器端已经确认了客户端的连接请求并准备好接收数据。效率和延迟增加握手的次数会引入额外的延迟和开销。每次握手都需要来回的数据交换和确认增加了连接建立的时间。由于 TCP 的设计目标是提供高效的数据传输因此三次握手被认为是一个合理的折衷方案既保证了可靠性又尽量减少了握手的次数。避免冗余或无效连接通过三次握手可以防止过期的连接请求和无效的连接建立。如果握手次数增加可能会导致更多无效连接的产生浪费网络资源和服务器资源 三次握手是用最小成本验证全双工通信信道是通畅的三次握手可以有效防止单机进行对服务器进行攻击服务器收到攻击本身就不是tcp握手该解决的但是如果握手有明显漏洞那就是握手的问题了 三次握手不一定非得成功最担心的起始是最后一个ACK丢失但是有配套的解决方案 链接是需要被管理起来的被OS管理起来的先描述在组织。维护一个连接是有成本的[时空] 三次握手也可称为四次握手因为服务器在应答的SYNACK也可以分开进行但是它们是不同的标志位所以可以一次发送过去 SYN 洪水SYN Flood是一种网络攻击方式旨在通过发送大量的伪造 TCP 连接请求SYN 包来超载目标服务器的资源使其无法正常处理合法的连接请求。 SYN 洪水攻击利用了 TCP 协议三次握手的过程中的漏洞。攻击者发送大量的带有伪造源 IP 地址的 SYN 包给目标服务器使得服务器在接收到这些 SYN 包后会为每个连接请求分配一定的资源包括内存和连接表项。然而由于伪造的源 IP 地址服务器在等待客户端发送后续的 ACK 包进行连接的建立时无法得到响应导致资源被浪费
为什么要连接因为要保证可靠性 tcp连接本身并不能直接保证可靠性实际上tcp建立连接的时候你怎么知道哪些报文丢了你怎么知道它是处于什么状态是通信状态还是断开状态哪些报文需要重传下一次重传的时间又是多长当前服务端收到了多少报文又发送了多少报文这些上面的特征都是要维护在tcp连接结构体中的正是有三次握手这样的机制所以才建立了双方连接结构体这样的共识正是有了连接结构体才能完成所谓的超时重传、流量控制等等策略。所以连接结构体是保证数据可靠性的数据结构基础而三次握手是创建结构体的基础所以tcp三次握手就间接保证了可靠性。
四次挥手 主动断开连接的一方最终状态是TIME_WAIT状态被动断开连接的一方两次挥手完成会进入CLOSE_WAIT状态这个与双方是服务器还是客户端无关因为TCP是地位对等的协议四次挥手动作完成但是主动断开连接的一方要维持一段时间的TIME_WAIT
如果我们的服务器出现了大量的CLOSE_WAIT
服务器有bug没有做close文件描述符的动作服务器有压力可能一直在推送消息给client导致来不及close
为什么主动断开连接的一方要维持一段时间的TIME_WAIT 一般维持2*MSL的时间目的是
保证最后一个ACK尽可能的被对方收到双方在断开连接的时候网络中还有滞留的报文为了保证滞留报文进行消散(教材给的理由)
服务器有时候可以立即重启有时候无法立即重启原因是bind_error
服务器主动断开服务器要维持TIME_WAIT状态维持该状态期间该端口与连接依旧存在所以你无法绑定该端口
解决TIME_WAIT状态引起的bind失败的方法
在server的TCP连接没有完全断开之前不允许重新监听某些情况下可能是不合理的服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短但是每秒都有很大数量的客户端来请求)。这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃就需要被服务器端主动清理掉)就会产生大量TIME_WAIT连接。由于我们的请求量很大就可能导致TIME_WAIT的连接数很多每个连接都会占用一个通信五元组(源ip、源端口、目的ip、目的端口、协议)。其中服务器的ip和端口和协议是固定的如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了就会出现问题 解决方法使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符 滑动窗口
我们确认应答策略对每一个发送的数据段都要给一个ACK确认应答收到ACK后再发送下一个数据段。这样做有一个比较大的缺点就是性能较差尤其是数据往返的时间较长的时候 既然这样一发一收的方式性能较低那么我们一次发送多条数据就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了) 发送方怎么在第一次就知道对方的接受能力呢?在通信之前早就做过了三次握手交换窗口大小 如果我们发送数据没有收到应答之前我们必须将自己的已经发送的数据暂时保存起来为了支持超时重传 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值上图的窗口大小就是4000个字节(四个段)。发送前四个段的时候不需要等待任何ACK直接发送收到第一个ACK后滑动窗口向后移动继续发送第五个段的数据依次类推操作系统内核为了维护这个滑动窗口需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答只有确认应答过的数据才能从缓冲区删掉窗口越大则网络的吞吐率就越高 窗口的开始大小是怎么设定的未来怎么变化 目前滑动窗口的大小和对方的接受能力有关 win_start 0; win_end win_start tcp_win – 未来无论怎么滑动都要保证对方能够进行正常接受 滑动窗口大小对方通告给我的自己的接受能力大小【目前】 确认序号的定义ACK seq X 1 标识X1之前的所有数据全部都收到了。这也是支持我们滑动窗口的滑动规则设定 1000已经丢包了那么我们肯定不能返回2000因为返回2000就代表1000已经应答了。
当TCP客户端发送序号为1000和2000的数据包时如果序号1000的数据包丢失了服务端并没有收到该数据包。因此它期望接收序号为1000的数据包。所以服务端会返回确认序号ACK为1000的ACK包。这意味着服务端告诉客户端“我已经成功接收了直到序号999的所有数据现在期待接收序号为1000的数据”。
简单地说服务端会返回序号为1000的ACK。
一直向后滑动如果空间不够了怎么办 其实发送缓冲区被内核组织成了环形结构上面的线性结构只是方便一开始的理解
拥塞控制 就如学校期末考试一样全班就你没及格你会觉得是你自己的问题但是全班就一个人及格可能就会认为是教学事故或其他原因。
这种发送10000条报文丢失了9999条的情况我们一般认为是网络出现了问题因为我们与Server端有可靠性策略
那么这种网络出现问题我们还进行超时重传吗不应该我们以前的各种超时重传互动窗口都是基于端对端的网络已经出现问题了我们如果继续发送会让网络中又出现大量的报文只会加重网络的故障问题。你可能觉得你的报文不多发一下对网络不会有太大问题但是如果TCP连接都这样那么整体而言会造成重大问题。 TCP的可靠性不仅仅考虑了双方主机的问题也考虑了路上网络的问题 – 拥塞控制背景 虽然TCP有了滑动窗口这个大杀器能够高效可靠的发送大量的数据但是如果在刚开始阶段就发送大量的数据仍然可能引发问题。
因为网络上有很多的计算机可能当前的网络状态就已经比较拥堵在不清楚当前网络状态下贸然发送大量的数据是很有可能引起雪上加霜的。 TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据 此处引入一个概念程为拥塞窗口
发送开始的时候定义拥塞窗口大小为1每次收到一个ACK应答拥塞窗口加1每次发送数据包的时候将拥塞窗口和接收端主机反馈的窗口大小做比较取较小的值作为实际发送的窗口我(滑动窗口)网络(拥塞窗口)对端(窗口大小自己的适应能力) — 我→网络→对端 — 滑动窗口大小 min(拥塞窗口,窗口大小)
像上面这样的拥塞窗口增长速度是指数级别的。“慢启动” 只是指初使时慢但是增长速度非常快。
为了不增长的那么快因此不能使拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阈值当拥塞窗口超过这个阈值的时候不再按照指数方式增长而是按照线性方式增长 当TCP开始启动的时候慢启动阈值等于窗口最大值在每次超时重发的时候慢启动阈值会变成原来的一半同时拥塞窗口置回1
少量的丢包我们仅仅是触发超时重传大量的丢包我们就认为网络拥塞 当TCP通信开始后网络吞吐量会逐渐上升随着网络发生拥堵吞吐量会立刻下降 拥塞控制归根结底是TCP协议想尽可能快的把数据传输给对方但是又要避免给网络造成太大压力的折中方案
延迟应答
如果接收数据的主机立刻返回ACK应答这时候返回的窗口可能比较小。
假设接收端缓冲区为1M一次收到了50OK的数据如果立刻应答返回的窗口就是500K但实际上可能处理端处理的速度很快10ms之内就把50OK数据从缓冲区消费掉了在这种情况下接收端处理还远没有达到自己的极限即使窗口再放大一些也能处理过来如果接收端稍微等一会再应答比如等待200ms再应那么这个时候返回的窗口大小就是1M
一定要记得窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率
那么所有的包都可以延迟应答么肯定也不是
数量限制每隔N个包就应答一次时间限制超过最大延迟时间就应答一次
具体的数量和超时时间依操作系统不同也有差异一般N取2超时时间取200ms 捎带应答
在延迟应答的基础上我们发现很多情况下客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”服务器也会给客户端回一个 “Finethank you” 那么这个时候ACK就可以搭顺风车和服务器回应的 “Fine, thank you” 一起回给客户端 面向字节流
创建一个TCP的socket,同时在内核中创建一个发送缓冲区和一个接收缓冲区;
调用write时数据会先写入发送缓冲区中如果发送的字节数太长会被拆分成多个TCP的数据包发出如果发送的字节数太短就会先在缓冲区里等待等到缓冲区长度差不多了或者其他合适的时机发送出去接收数据的时候数据也是从网卡驱动程序到达内核的接收缓冲区然后应用程序可以调用read从接收缓冲区拿数据另一方面TCP的一个连接既有发送缓冲区也有接收缓冲区那么对于这一个连接既可以读数据也可以写数据。这个概念叫做全双工
由于缓冲区的存在TCP程序的读和写不需要——匹配例如
写100个字节数据时可以调用一次write写100个字节也可以调用100次write每次写一个字节读100个字节数据时也完全不需要考虑写的时候是怎么写的既可以一次read 100个字节也可以一次read一个字节重复100次
粘包问题
首先要明确粘包问题中的包是指的应用层的数据包。比如你前一个序列的报文少读取一部分同时也会影响下一个序列号的报文读取这就是粘宝。
在TCP的协议头中没有如同UDP一样的报文长度这样的字段但是有一个序号这样的字段。站在传输层的角度TCP是一个一个报文过来的按照序号排好序放在缓冲区中站在应用层的角度看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包
那么如何避免粘包问题呢? 归根结底就是一句话明确两个包之间的边界
对于定长的包保证每次都按固定大小读取即可。例如上面的Request结构是固定大小的那么就从缓冲区从头开始按sizeof(Request)依次读取即可对于变长的包可以在包头的位置约定一个包总长度的字段从而就知道了包的结束位置对于变长的包还可以在包和包之间使用明确的分隔符(应用层协议是程序猿自己来定的只要保证分隔符不和正文冲突即可)
思考对于UDP协议来说是否也存在粘包问题”呢?
对于UDP如果还没有上层交付数据UDP的报文长度仍然在同时UDP是一个一个把数据交付给应用层就有很明确的数据边界站在应用层的站在应用层的角度使用UDP的时候要么收到完整的UDP报文要么不收不会出现半个的情况。
TCP异常情况
进程终止进程终止会释放文件描述符仍然可以发送FIN和正常关闭没有什么区别(OS会正常自动四次挥手跟close没有区别)
机器重启和进程终止的情况相同
机器掉电/网线断开接收端认为连接还在一旦接收端有写入操作接收端发现连接已经不在了就会进行reset即使没有写入操作TCP自己也内置了一个保活定时器会定期询问对方是否还在如果对方不在也会把连接释放。另外应用层的某些协议也有一些这样的检测机制。例如HTTP长连接中也会定期检测对方的状态例如QQ在QQ断线之后也会定期尝试重新连接。(OS没有时间反应客户端识别到网络变化但是服务器不知道客户端想要告诉服务端也没有办法因为先拔的网线。这个时候就会。服务端认为连接是好的客户端认为连接已经关闭了。服务端可能采取某些策略过一段时间询问一下客户端还在不在。)
TCP小结
为什么TCP这么复杂?因为要保证可靠性同时又尽可能的提高性能 可靠性
校验和序列号(按序到达)确认应答超时重发连接管理流量控制拥塞控制
提高性能
滑动窗口快速重传延迟应答捎带应答
其他
定时器(超时重传定时器保活定时器TIME_WAIT定时器等)
基于TCP应用层协议
HTTPHTTPSSSHTelnetFTPSMTP
当然也包括你自己写TCP程序时自定义的应用层协议
理解 listen 的第二个参数 客户端状态正常但是服务器端出现了 SYN_RECV 状态而不是 ESTABLISHED 状态 这是因为Linux内核协议栈为一个tcp连接管理使用两个队列
半链接队列用来保存处于SYN_SENT和SYN_RECV状态的请求全连接队列accpetd队列用来保存处于established状态但是应用层没有调用accept取走的请求
而全连接队列的长度会受到 listen 第二个参数的影响. 全连接队列满了的时候就无法继续让当前连接的状态进入 established 状态了 这个队列的长度通过上述实验可知是 listen 的第二个参数 1
这个队列本质上就是给服务器维护的一个短暂的缓冲区用来随时填补服务器上层服务完毕的时候直接从队列拿取新连接。 如有错误或者不清楚的地方欢迎私信或者评论指出
