TCP 可靠性保证

1、确认应答(ACK)机制

TCP 将每个字节的数据都进行了编号,即为序列号。确认序号 = 序号 + 1

每个 ACK 都有对应的确认序列号,意思是告诉发送者已经收到了数据,下一个数据应该从哪里开始发送

2、超时重传机制

两种情况:
(1)主机 B 在规定的时间内没有及时收到主机 A 发送的报文

(2)主机 A 未收到 B 发来的确认应答

这时主机 B 会收到很多重复的数据,那么,TCP 协议需要能够识别出哪些包是重复的包,并且把重复的包丢弃,这时可以用前面提到的序列号,很容易做到去重的效果

超时重传时间的确认

超时重传的时间设置的太短,会引起很多报文的不必要重传; 时间设置的过长,又会使网络的空闲时间增大,降低传输效率

TCP 采用了一种自适应算法,它记录一个报文发出的时间,以及收到相应确认的时间,这两个时间之差就是报文的往返时间 RTT

最理想的情况下,找到一个最小的时间,保证确认应答一定能在这个时间内返回。Linux 中,超时以 500ms 为一个单位进行控制,每次判定超时重发的超时时间都是500ms 的整数倍;如果重发一次仍然得不到应答,等待 2 * 500ms 后再进行重传;如果仍然得不到应答,等待 4 * 500ms 进行重传,依次类推,以指数形式递增;累积到一定的重传次数,TCP 认为网络或者对端主机出现异常,强制关闭连接

3、连接管理机制

TCP 面向连接,可靠性传输

4、流量控制

发送端根据自己的实际情况发送数据。但是,接收端再高负荷情况下可能无法接受任何数据。如此一来,如果接收端将本应该接收的数据丢弃,就会触发重发机制,从而导致网络流量的无端浪费

TCP 它提供了流量控制机制可以让发送端根据接收端的实际接收能力控制发送的数据量

流量控制的实现方法:接收端将自己可接受的缓冲区大小放入 TCP 首部中的 “窗口大小字段”,通过 ACK 通知发送端。窗口大小字段越大,说明网络的吞吐量越高;接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值给发送端;发送端接受到这个窗口之后,就会减慢自己的发送速率;如果接受缓冲区满了,就会将窗口设置为 0,这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端

5、拥塞控制

虽然有了滑动窗口机制,如果一开始就发送大量数据,很有可能引发很多问题

TCP 加入慢启动机制,先发少量的数据探探路,看看当前网络的拥塞状态,再决定按照多大的速率进行传送

慢启动时,定义拥塞窗口的大小为 1,每次接收到一个 ACK 应答,拥塞窗口值加 1,每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值作为实际发送的数据量

这样的拥塞窗口增长的速度是指数级别的,慢启动只是指初始时慢,但是增长速度很快,不久就可以造成网络拥塞。为了不让窗口一直加倍增长,我们引入一个慢启动的阈值,当拥塞窗口超过这个阈值的时候,不再按指数方式增长,而是按照线性方式增长

当 TCP 初次启动时,没有设置慢启动阈值,每次超时重发的时候,慢启动阈值会变为原来的一半,同时拥塞窗口置回 1

当 TCP 通信开始后,网络吞吐量会逐渐上升,随着网络发生拥堵,吞吐量又会立即下降。于是会再次进入吞吐量慢慢上升的过程。因此 TCP 吞吐量的特点就好像是再逐步占领网络带宽的感觉

拥塞控制,归根结底是 TCP 协议想尽可能快的把数据传输给对方,但又要避免给网络造成最大压力的最好方案

TCP 提高性能的 5 种机制

1、滑动窗口

滑动窗口:窗口之前的数据都已经发送并确认;窗口中的数据已经发送,还没被确认;窗口之后的数据还未被发送

当发送一次数据,等到确认应答时才可以发送下一个数据段,这样的效率会很低,利用滑动窗口,可以无需等待确认应答而继续发送数据;收到第一个 ACK 后,滑动窗口向后移;操作系统为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有那些数据没有应答,只有确认应答过的数据,才能从缓冲区删除掉

在使用窗口控制中,出现段丢失怎么办?

先考虑应答未能返回的情况。这种情况下数据已到达对端,在没有使用窗口控制时,没有收到确认应答的数据都会被重发;而使用窗口控制后,某些确认应答即使丢失了也无需重发

其次考虑报文段丢失的情况,见快速重传

2、快速重传

接收主机如果收到一个自己应该接收的序号以外的数据时,会针对当前收到数据返回确认应答。不过即使接收端主机收到的包序号并不连续,也不会将数据丢弃而是暂时保持至缓冲区中

在窗口比较大,又出现报文段丢失的情况下,同一个序号的确认应答将会重复不断地返回。而发送端如果连续 3 次收到同一个确认应答,就会将其所对应地数据进行重发。这种机制比上面提到的超时重传更高效,因此被称为快速重传

TCP 快速重传为什么是三次冗余 ACK ?

3、Nagle 算法

发送端即使还有应该发送地数据,但如果这部分数据很少的话,则进行延迟发送。具体来说,就是仅在下列任一条件下才能发送数据。如果两个条件都不满足,那么暂时等待一段实际后再进行数据发送

  • 已发送的数据都已经收到确认应答时
  • 可以发送最大段长度(MSS)的数据时

该算法虽然可提高网络利用率,但可能会发生延迟,可关闭

4、延迟应答

收到数据以后并不立即返回 ACK,而是延迟一段时间(得益于滑动窗口机制)
TCP 文件传输中,绝大多数是每两个数据段返回一次确认应答

5、捎带应答

在同一个 TCP 包中既发送数据又发送确认应答的机制

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,864评论 6 494
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,175评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,401评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,170评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,276评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,364评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,401评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,179评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,604评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,902评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,070评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,751评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,380评论 3 319
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,077评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,312评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,924评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,957评论 2 351

推荐阅读更多精彩内容