目录一、手写原稿第一页确认应答与序号二、手写原稿第二页流量控制与标志位三、拼接的打字稿标志位、握手挥手、序号丢包、连接管理、滑动窗口四、存疑读法汇总请核对1.通信过程1、Client 和 server 某一方给另一方发消息时另一方必须对对方应答但我们不对应答作应答这样就能得到某一方对另一方的可靠性。第一必须对对方应答要限定范围TCP 不是收到每个报文都立刻回一个 ACK接收方可以延迟确认也可以对连续多个报文只回一个累计确认。第二不对应答作应答的原因要写出来确认序号是累计的下一次发送数据时捎带的 ACK 就把前面所有数据一起确认了可靠性的方向是单向逐段累积出来的即我只是告诉对方我接收到了不需要对方回应。现在实现是一条一条发只是连续发送多条而不等前一条的 ACK。收到的应答也不一定与报文一一对应因为确认序号是累计的一个 ACK 可以确认一整段数据。另外更现代不是 TCP 的机制名这是滑动窗口加累计确认带来的效果。client 给对方发序号对方应答回的确认序号(值是序号 1)应答成功代表确认序号之前的字节将缓冲区看成字符数组都成功接收到了。确认序号做的是累计确认它表示这个序号之前的字节都已经按序收到。TCP 里没有报文边界所以不能说之前的报文都收到了这句话的意思是tcp不认识报文。下一个报文发送的序号值就是上一个报文的确认序号值补充:允许丢应答的前提是确认序号累计后一个 ACK 到达就说明它前面的数据都到了所以中间丢几个 ACK 不影响可靠性。但要补一句如果最后一个 ACK 也丢了发送方仍要靠超时重传补上只是不会重复传已经确认过的数据从最初一个未被确认有应答的报文开始重传。乱序问题client 按顺序发但 server 不一定按顺序收。按序发不等于按序收中间可能换路径也可能有丢包重传所以接收方要按序号重排把不连续的那部分先缓存起来。如果有了序号 就能根据序号排序解决乱序问题。ACK 能搭在任意报文上不只是因为往来的都是 TCP 报文而是因为一个 ACK 只占一个标志位加一个 32 位确认序号字段任何报文都带得下。应答是报头里 ACK 标志位加确认序号字段的组合。接收方本来就有数据要发给对方时就把确认序号填在这条数据报文的 TCP 报头里同一个报头里的序号给自己的数据编号确认序号给对方的数据开收据于是一条报文既确认了对方的字节又携带了自己的字节对方按序号把它按序接收这就是捎带应答也就是接收方有数据要发时顺手在报头里填上确认序号。二、流量控制与标志位流量控制减少了接收端缓冲区满了接收不了报文被迫丢弃的情况。做法为流量控制的做法是接收方在报头里通告自己还能收多少字节窗口大小发送方据此调整发送量目的是不让接收缓冲区溢出。另外丢包也不是被迫这么简单缓冲区满时到达的数据会被直接丢弃TCP 再靠重传补回来所以流量控制降低的是丢包和重传的概率。缓冲区接收报文的能力取决于剩余缓冲区大小的能力。16 位窗口大小字段用来通告本端剩余的接收缓冲区大小也就是本端还能再接收多少字节。对方根据此动态调整报文传输速度。ACK 由内核协议栈生成并发送上层并不知道。其实上层并不知道太绝对应用层通过 socket 能间接感知例如 send 阻塞、返回 EAGAIN或者用 TCP_INFO 查连接状态只是不参与 ACK 的生成。窗口通告同样由内核填写应用层一般不参与。这个字段由发出该报文的一方填写写的是它自己还能收多少收到这个报文的那一方才根据它调整发送速度。16 位最大只能表示 65535 字节要通告更大的窗口得用窗口扩大选项。16 位窗口大小写的是发出这条报文那一方自己的剩余接收空间也就是它还能再收多少字节把这个数字告诉对方是为了让对方据此调整发送速度。TCP报头本身也是一个结构体。更准确的说法是内核用结构体来表示 TCP 报头网络上传的仍然是按固定顺序排列的字节。接收方之所以能用同一个结构体解析是因为报头字段定长只有选项部分是变长的。三、标志位、握手挥手、序号丢包、连接管理、滑动窗口1.标志位标志位的意义其本质是几个bit。接收方收到的报文一定会存在不同的类型(如申请连接数据传输或断开连接针对于不同的报文类型接收方要有不同的做法)而表明不同类型的字段就是标志位。标志位可以组合不同组合对应不同行为。三次握手的过程中前两次握手中不能携带信息就是第一次的 SYN 和第二回的 SYN 加 ACK 都不能携带数据SYN 自身还要占掉一个序号。第三次的 ACK 在协议上是允许携带数据的只是实现上通常不带因为此时服务端可能还没 accept。其中第一次为SYN,第二次为SYNACK,第三次为ACKSYN同步标志位只能用于建立连接或握手过程表明自己是一个建立连接相关的报文本质是对对应的标志位数字置为1别的场合不用。更准确的说法是SYN 置 1 表示本报文携带初始序号请求建立连接并同步序号。在三次握手的时候双方就已经明确对方的接收能力了而且不存在数据丢失因为三次握手过程不携带数据也就是用户在开始交流时不用担心不知道对方的接收能力而导致报文丢失。补充第一第三次握手的 ACK 协议上可以带数据不能说握手过程一律不带数据。第二握手时交换的窗口只是当时的通告值之后每个报文都会重新通告接收能力是动态变化的。ACK:表明自己是一个应答报文该标志位几乎一直是设为1的可以说除了第一个 SYN 报文之外连接建立之后的报文 ACK 一般都置 1所以更准确的说法是除首个 SYN 外几乎总是 1。4次挥手用于断开连接次数不同是因为建立连接只需要接收方同意但断开连接需要双方同意断开连接的本质是关闭全双工断开连接是两个方向各自关闭自己的发送方向也就是半关闭等两个方向都关闭全双工才真正结束这才是 FIN 要来回各走一次的原因。FIN结束报文段通知对方本端要关闭了PSH:提示内核尽快把数据从接收缓冲区交付给应用层但读不读由应用层决定(其实读取数据在缓冲区数据不多的时候可能是不会读的此时PSH就可以提醒直接要求应用层读取缓冲区中的数据)PSH 通常由内核在发送缓冲区被取空时自动置位应用层很少自己控制。RST(建立连接不一定成功报文传输斜着画是为了表示时间)其是复位标志位用在异常场合例如收到的报文不属于任何一条已建立的连接、连接已经被对端释放而本端还在发数据。括号里的建立连接不一定成功可以展开成两种情形服务端还在等第三次握手时或者服务端已经把这条半连接丢弃之后收到它不认识的报文就会回 RST。三次握手时第三次发送时客户端是无法知道接收方是否接收到报文的因此在客户端将自己的ACK发送过去时就认为三次握手建立成功而接收方在收到第三次ACK才认为建立成功也就是说双方对连接已建立这一状态的确信时刻不同存在时间差。补充一点客户端在发出 ACK 时还要等对方的第一个数据报文或按超时重传机制确认实际实现里没这么干脆。也就是说双方在建立连接是存在时间差的而如果ACK本身的报文发送错误这会造成双方对连接建立成功的认知不一致此时如果后面client成功发送数据给接收方了接收方发现连接错误后就会发送具有RST标识符的报文给client说明之前的连接失败了要求重新建立连接。服务端如果只是在等第三次握手它收到带 ACK 的数据报文会把它当作第三次握手完成连接数据进入接收队列不会回 RST。真正会回 RST 的是另一种情况服务端已经把这条半连接丢弃了重传 SYN 加 ACK 达到上限后此后收到客户端的报文因为找不到对应连接才回 RST。对方收到 RST 时接收缓冲区里没读完的数据会被丢掉应用层通常直接读到连接被重置的错误。URG:配合16位紧急指针使用URG为0说明紧急指针无效否则有效序号能解决按序重组和去重从而保证接收缓冲区中就是字节流式的有顺序的接收队列。这种特点无法解决有数据想被优先读取优先处理的情况补充字节流严格按序号排队后到的数据不会插队这正是 URG 想解决的问题只是现代系统里 URG 基本被忽略优先处理多半交给应用层自己做。应用场景:在上传数据时想取消此时接收方的接收缓冲区中已经有不少数据了要想该报文迅速得到响应就要使用URG来让这条报文插队紧急数据并不属于常规数据叫带外数据。16位紧急指针的数据意义为在当前报文的序号字段中的特定偏移量有紧急数据也就是说他就是一个偏移量加出来的结果是紧急数据之后那个字节的序号。协议规定紧急数据至少一个字节并不是只能有一个字节。它的作用只是告诉应用层有带外数据到了具体含义由应用自己约定例如 Telnet 用带外的中断命令。把设置状态码、发送控制命令写成协议规定是把某一类应用的用法当成了 TCP 的规定。序号:将发送缓冲区想象成一个char类型的数组也算是一个字节流在发送缓冲区中每一个字节就天然有编号了即为序列号表示的是要发送的是在发送缓冲区中的某一范围的字节段序号字段记录的是本报文数据第一个字节的编号本报文携带的数据范围是序号到序号加数据长度减一。确认序号表示期望对方下次发来的字节编号。数据丢了应答丢了发送方没有接收到应答意味着无法100%保证对方是否接收到消息也就是无法保证可靠性在发送方特定的时间间隔中收不到应答时就判定丢包了这个时间间隔叫重传超时时间 RTO它由往返时延 RTT 的测量值动态估算出来超时后判定为丢包并重传。超时重传等待应答一段时间后还没有就重传这个重传超时时间 RTO是会随着环境而动态变化的它随往返时延动态变化同时有上下限不能无限增长也不能无限缩小。以linux为例每次超时设置以500ms为单位每一次超时就重传然后超时时间设为500ms*(2^重传次数)一定次数后就达到重传上限后放弃并向上层报错。Linux 的初始 RTO 是 1 秒最小值 200 毫秒最大值 120 秒500 毫秒是教材举例不是 Linux 的固定值。连接管理机制三次握手一个连接有多种状态状态是针对于某一方的具体情况设置的。状态就是一个整数宏值。server会同时与多个client建立连接于是采用先描述再组织的方式管理因此一个连接的本质就是双方双方各自维护一个格式相同的描述连接的结构体。connect只是向对方发起三次握手accept不参与三次握手,握手的具体过程由双方的os自行完成生产消费模型所带来的解耦成功让用户层和OS对同一件事情的看法不同三次握手的意义1.以最短的方式验证全双工本质是在验证我们两个所处的网络是通畅的能够支持全双工。2.以最小成本确定双方的通信意愿。三次握手的本质是4次握手接收方的ACK和SYN原来是两个应答(也就是发送方是SYN接收方是ACK)只是二者合并成了一个捎带应答。其实4次挥手也可以压缩成3次4次握手变成三次握手的原因是server面对client的连接请求都要无脑接受但断联可以不接受(无脑接受有限定范围内核在 SYN 队列和 accept 队列没满时确实会直接完成握手但队列满了会丢弃或不应答拒绝发生在队列层面只是应用层没有握手的否决权。)4次挥手FIN:说明要发送的数据已经发完要断开连接tcp通信是全双工的,client向server发的FIN是在说明他要发的数据已经发完了因此要断开。由于全双工特性server向client可能还没有发送完数据所以在server向client发FIN报文前可能还会有server向client发送的报文在这些报文发送完时server才会向client发FIN报文这也就是不能压缩成3次挥手的原因被动关闭方收到 FIN 后进入 CLOSE_WAIT此时它仍然可以继续发送数据等自己发完再发 FIN这个中间状态正是四次挥手拆开的原因。int shutdown(int sockfd,int how);shutdown 关闭的是某个方向的数据流SHUT_WR 只关闭本端的发送方向套接字本身还在所以本端仍然能接收对方的报文只有 close 才会回收描述符。三次握手和四次挥手动作数不同原因在于握手时服务端收到客户端的 SYN 后自己也要发起连接而此刻它没有数据要发于是可以把确认客户端和发起自己方向合并进同一个 SYNACK 报文三次就能完成断开连接时被动方收到 FIN 后往往还有数据没发完只能先回 ACK等数据发完再发自己的 FIN这两个动作合并不了所以仍然要四次。客户端主动关闭时要依次经过 FIN_WAIT_1、FIN_WAIT_2 才到 TIME_WAIT所以在客户端已经关闭而服务端仍不关闭的这段时间里客户端通常停在 FIN_WAIT_2这个状态并非永久对端迟迟不发 FIN 时内核有 tcp_fin_timeout 兜底Linux 默认 60 秒超时就直接销毁连接与此同时服务端处于 CLOSE_WAIT此状态下通信用的 fd 依然存在连接并未释放只有服务端也想退出时才会进入 LAST_ACK。用完的fd就必须关闭作为一种资源终会用完用完的fd不关闭叫fd泄露问题CLOSE_WAIT的半关闭状态会浪费内存资源半连接通常指 SYN_RCVD 这种三次握手还没完成的连接不关闭的fd会浪费内核里连接结构体和收发缓冲区的内存client在发送完最后一个ACK后需要等待一段时间才能CLOSE连接处于CLOSE_WAIT状态的只能用户调用close接口才能完成4次挥手不然要等进程退出时由OS回。更正错别字可能应为只能以及调用应为显式调用不然要应为不然就等。意思对CLOSE_WAIT 不会自己消失必须应用调用 close或者等进程退出时由内核统一回收。MSL是tcp报文的最大生存时间两倍MSL为了保证双方报文都能消散。主动关闭连接处于TIME_WAIT状态的一方要等待两个MSL时间才能close意义某些由发送方发出由于超时而判定不存在但实际仍在网络中传输的报文在双方连接已经关闭又立刻建立新连接时前提旧报文能干扰新连接的条件是两条连接的四元组相同源 IP、源端口、目的 IP、目的端口这个旧报文就可能影响新连接的建立和通信这种报文叫历史残留数据的报文MSL的等待时间就能保证历史残留报文的消散。TIME_WAIT时fd还是在占用着的连接还是在的因此在此时TIME_WAIT时重启原port还是在占用着的也就是立刻用原port重启会出现bind error的原因用途在处于time_wait期间如果ack发送失败对方一定会有重发fin的机会如果在这段时间没有再次接收到fin,就默认ack成功发送了,补充如果最后一个 ACK 丢了对端会超时重发 FIN本端收到重发的 FIN 会再回一个 ACK 并重新计时所以 TIME_WAIT 给的是对端重发 FIN 的机会避免对端一直卡在 LAST_ACK。让断开连接方处于time_wait的同时又能立刻重启的操作就是使用setsocketopt接口配合 SO_REUSEADDR 选项SO_REUSEADDR 要在创建套接字之后、bind 之前设置作用是让 bind 允许复用处于 TIME_WAIT 的地址端口并没有被立刻释放也就是新连接是直接忽视了该接口的TIME_WAIT状态TIME_WAIT 限制的只是同一个地址再 bind新连接照样正常通信在双方开始进行通信时最初的序号值其实是一个随机值这也可以保证一个新连接在接收到上一次连接的报文时能通过序号的值是否与当前矛盾来判断报文的合法性(补两点。第一初始序号不是纯随机数它由时钟加上四元组哈希生成RFC 6528 的做法目的是让别人猜不出下一个序号同时避免旧连接的报文混进来。第二判断合法性看的是序号是否落在当前接收窗口范围内落在窗口外的报文会被丢弃或触发一个 ACK。)滑动窗口发送方一次向对方发多少数据由滑动窗口决定滑动窗口是发送缓冲区的一部分也就是一段下标范围(int start,int end);范围是end - start以滑动窗口为界我们能分出三部分前面叫(已发送已确认)(可以直接发暂时不要应答)待发送三段。标准分法是四段。第一段已发送并已确认第二段已发送但未确认第三段可以发送但还没发第四段还不能发送。原稿把第二段和第三段合成一段了其实前者要等 ACK后者才可以直接发。已发送已确认说明这部分数据已经被确认缓冲区空间可以回收复用接收方那边已经收到本地不必再保留。可以直接覆盖序号在发送的轮次中不断增大意味着滑动窗口基本是在缓冲区中向右移动的而其移动的本质就是start和end滑动窗口的大小 对方的接受能力因此滑动窗口的本质是流量控制的具体实现方案,且滑动窗口的大小是可以动态调整的。实际能发多少取对方通告的接收窗口与拥塞窗口中的较小值流量控制只看接收窗口这一半。更新时start 报文的确认序号end start 16位窗口大小丢包问题的基本分类1.左侧丢失1数据丢了窗口的左侧不变具体过程是叫快重传左侧丢失后接收方收到不连续的报文时会返回之前最新的应答后面的报文也如此当发送方接收到 3 个重复 ACK 就触发快速重传就能明白至少从应答序号开始后面有一个报文丢失从而进行重传重传(重传只传明确丢失的)成功后下次应答直接就是跳到已连续收到的最大位置剩下的空洞会被后续的重复 ACK 继续暴露同样触发重传。重传机制存在两种快重传用于提高效率超时重传用于兜底两种重传的数据都是存在滑动窗口中也就是这两种重传都是由滑动窗口支持的2应答丢了正常移动因为有后面的应答兜底总结有滑动窗口的左侧在没有接收到应答时就不会移动只会当重传到应答确认了才向右滑动这句整体只在有数据待确认时成立如果本地没有数据要发窗口不会因为收不到应答就卡住。2.中间丢失前面确认了的会往右移动最终变成左侧丢失3.右侧丢失同理本质还是最左重传在没有接收到应答前报文还得暂时保存起来存储在滑动窗口中接收到应答滑动窗口就向右移动可以说滑动窗口以报文为单位移动只是收到累计确认时会直接移动一大段而已。窗口左右边界都是字节序号移动单位是字节不是报文说以报文为单位只是为了好理解。