2018-01-20

只是自说自话的学习笔记,各路看官绕路~

TCP协议:

1、tcp协议被定义为可靠的协议,但是它是属于传输层的协议,根据七层协议的定义,传输层的数据会先传网络层(ip层),而ip层是尽最大努力做到交付,这里可以理解成ip层也是不可靠的协议,那么在ip层之上的tcp协议如何做到可靠交付呢?这里要提到几个处理方式:

  • 停止等待处理方式
    停止等待处理方式可以用一下的例子来举例:a通过tcp协议将数据传送给b,而在tcp协议定义里边,这些数据是需要被分组发送的,当然了这个分组情况是tcp协议自身决定的,而a每次将数据中的一小组发送给b的时候都需要b发送数据给a确认已经成功接收到数据,这样a才会继续将数据发送给b,那么网络有时候会出现异常导致b无法成功接受到数据或者数据出现错误的情况a和b怎么处理呢?b在这里是如果接受到错误信息就直接丢弃然后不返回任何数据通知a,如果b无法接收到数据就不做处理,a在这里的处理方式是给每次发送数据设置一个计时器,如果超过这个时间了b还没有发送确认消息,a就默认这次发送失败,然后再次发送数据给b,这里也被称之为“超时重传”和"自动重传请求机制",如果收到了b的确认信息则自动将计时器关闭。所以这里这个计时器的时间的设定就显得非常重要了,因为这个时间要比正常成功传输的时间稍微长一些,如果短了导致多次重传,浪费网络资源,而长了就会导致效率边长,而且这个正常成功传输的时间也不好确定,因为和经过哪些网络有关系。那么问题来了,b在接收到a重传之后如何处理的呢?首先b是先判断是否已经有了这个数据,如果有了就则直接丢弃这个数据,如果没有则继续向会话层和应用层交付数据,而无论如何,都要再次发送数据和a进行确认,因为之所以会导致这个情况就是因为a没有收到确认信息导致的。
    通过这种方式,tcp协议就能在ip层不可靠的传输之上实现可靠的传输了。
    不过这里如果是每次要等到数据1发送成功后才继续发送数据2,数据1和数据2都在同一个分组里边,就显得效率太低了,那么如何做到高效率呢?这里采用了另一种机制,那就是流水线传输,就是说发送方可以并行发送多个数据,而不是说串行的发送,这样以来效率方面也就提高了。

  • 利用tcp协议如何实现流量控制?这里所谓的流量控制指的是让发送方的发送速率不要那么快,让接收方及时处理,采用的是滑动窗口的处理方式;以a和b发送例子为例,a和b在建立连接的时候(三次握手的时候),b会告诉a它的缓存队列中还可以存储多少个字节(rwnd),而a再根据b告诉它的rwnd的值来传输数据,技术细节:b每次告诉a的时候首部ACK的值为1,小写ack的值是确认的序号,而这里a传输数据的时候会带上seq,即传输数据的开始部分,如果b告诉它的rwnd是100,则此刻a传输的数据是(1~100)。而等b告诉a的rwnd为0的时候证明b这边不允许发送方再发送数据了。而如果b又可以接收数据了,就会再次发送一个rwnd的值告诉a,那么问题来了,如果传输的时候b的网络不好,导致rwnd的值丢失了怎么办?解决方案是:a在接收到b的零窗口的时候(rwnd=0),a会激发一个计时器,每隔一段制定的时间发送一个零窗口探测器,而b在接收到这个零窗口探测信息的时候就会给出目前的窗口值,从而解除了互相等待的状态。


tip: 这里保持一个问题,刚刚提到的滑动窗口的传输方式其实是针对字节实现的,那么问题来了?tcp传输是数据报的形式实现的,那么为何此处是根据字节实现的呢?


  • 更详细的三次握手流程:这里以a发送方和b接收方为例,b作为接收方会先开启监听状态,监听是否有发送方做连接请求,这里称之为服务器,而a作为发送方这里称之为客户端,第一次握手:a的tcp协议首部中设置SYN=1,seq=x之后将数据报发送给b,此处SYN=1的时候规定不准携带数据,但是序号会自增。完成这一步操作后a的tcp状态会变为SYN_SEND状态。第二次握手:b在接收到a的数据的时候会根据SYN=1判断是有客户端连接,b在tcp数据包的首部中会将ACK=1,ack=x+1,并且再生成seq=y,将数据报发送给a做确认,此刻b的状态会变为SYN_RCVD状态。第三次握手:a在接收到ACK=1的数据后通过ack=x+1明白是b的确认,a就会将ACK=1,ack=y+1,sql=x+1,再次发送给b,之后进入ESTABLISHED状态,在这一次的操作中允许携带数据,如果不携带则序号不会增加。

tip: 这里将会产生一个问题,如果去掉第三次连接会怎么样呢?这里给出一个例子来解答这个问题,结合以上的知识点可以知道,如果在a第一次握手的时候出现了网络滞留或者丢失问题,a的协议机制有个计时器,超时了会再次发送请求,这也a就发送了两次请求连接的操作,而由于网络滞留问题,其中有一次操作在该连接结束后b才收到,那么如果是两次握手就结束的话,那么b此刻就会进入established状态,开始等待a的数据传输,可是a并没有打算将数据传输给b,这也b就会造成等待,导致b的资源浪费。


  • 结合以上知识点来说说看更详细的四次挥手的流程:这里同样以a和b进行tcp连接为例,a在要断开和b的tcp连接的时候,a会先将头部的FIN信号设置为1,序号seq=u,即最后一次传送的序号+1,然后发送数据包,之后进入FIN-WAIT-1状态,等待b的确认。这也是第一次握手的过程。b在收到a的数据包之后,会根据FIN为1判断是有客户端要进行挥手连接,b会将ACK信号设置为1,ack=u+1,然后发送数据包,之后就会进入CLOSE_WAIT状态,此刻A到B的这个连接就已经断开了,即a没有数据要发送了,这时TCP连接就进入了半关闭状态,因为tcp是双全工连接,a到b的连接断开了,可是b到a的连接还在,而a在接收到b的数据包之后便进入了FIN-WAIT-2的状态,等待b释放连接,此刻便完成了二次挥手,第三次挥手是b会发送一个FIN数据包,会再次发送ack为u+1的数据包,此刻b便进入LAST_ACK状态,第三次挥手结束,而第四次挥手是a在接收到b的数据包之后,会根据FIN和ack=u+1判断是第三次挥手,之后a会发送一个ACK数据包,然后进入TIME_WAIT 状态,这里有个地方要注意的,那就是此时TCP连接尚未关闭,而是要等一个计时器的时间,之后才进入CLOSE状态,而b在接受到数据报纸后也会进入CLOSE状态。

tip: 这里将会产生几个问题:

  • 问题一?为什么在第四次挥手a要等待一个计时器的时间才进入CLOSE状态?主要原因有:如果a的网络不好,在第四次挥手的时候发送的数据包被丢弃掉了,这样b就会由于没有收到确认信息而重发数据包,如果a即可就进入CLOSE状态了那么肯定无法在此刻接收到b的数据,而让a等待一个计时器的时间就可以解决这个问题了。
  • 问题二?在a释放tcp连接处于第二次挥手的时候a关机了,那么b会处于什么状态?并且b怎么处理这种情况?如果a关机了,那么b会处于LAST-ACK状态,之后会在发送数据给a的时候无法接受到a的确认数据包,为了不让b无限等待下去,b会启动一个保活计时器机制,b会在通常两个小时后还没有接收到数据包的话发送一个探测报文段,以后会间隔75分钟发送一次,如果10次之后还没有响应,则断开连接。
  • 问题三?服务器tcp连接存在大量close_wait状态,为什么?这里有个地方上面没有提到,以为close_wait状态迁移到last_ack状态是自发的,其实不是,是要socket.close()才会过度到last_ack,那么大量连接处于close_wait状态证明没有及时close掉socket,可能是io阻塞问题。

2、tcp协议中使用到的比较高效率的算法:

  • Nagle算法:Nagle算法的目的主要是用来解决a和b tcp协议传输的数据传送的过程,过程是:应用层的应用将要发送的数据逐个字节传输给传输层的tcp的发送缓存的时候,tcp先把第一个字节发送给接收方,把之后数据继续缓存起来,等到接收方回应之后,传送方再把缓存的数据发送出去,然后等到接收方回应,再继续传送缓存的数据给发送方,这里有点串行的方式。Nagle还规定:当送达的数据已经达到发送窗口大小的一半时就立即发送数据包。
    那么问题来了,将滑动窗口机制和这个结合,可以知道发送方发送数据是需要接收方告知发送的rwnd是多少的,而Nagle算法这里,先将第一个字节发送给接收方,而如果此时接收方的缓存队列中接收到这个字节后就满了,而交互式的应用进程这里是一个个从缓存中读取字节的,如果读取完接收方就发送确认并告知rwnd为1,而发送方收到确认后再次发送一个字节过来,接收方再次一个字节的处理,长此以往,效率肯定是很低的,那么如何解决呢?tcp协议是这样处理的,接收方在rwnd少的时候会先积累下来,等到多了再去通知发送方,而发送方在数据包少的时候也会积累下来,等到足够量再发送。

下面记录的算法是在拥塞控制的时候使用到的算法:

  • 慢开始算法:发送方会先维持一个拥塞窗口, 拥塞窗口的大小取决于网络的情况,只要网络没有出现问题,那么拥塞窗口就会变大,慢开始算法是成倍变大,那么tcp协议如何识别网络出现问题呢?从上面应该可以看到,发送方在发送出数据包的时候,如果没有收到确认数据包,那么便会当做网络出现问题处理。如果收到了确认数据包,则拥塞窗口就会变大,之所以会成倍变大,这里的意思是 如果拥塞窗口是4,则发送方会发送4个数据包出去,都收到应答之后,拥塞窗口变回成倍变大,拥塞窗口默认值为1,并且会设置一个ssthresh慢开始门限,那么如果遇见了网络阻塞,发出去的数据包没有应答的话怎么处理?如果遇见了ssthresh会减半处理,并且拥塞窗口的值会降为1,而如果一直拥塞窗口的值一直增加到超过ssthresh之后便会采取拥塞算法,在这个阶段和慢开始阶段不同的地方在于,发送方发送的数据包串行化的逐个发送的,也即是说拥塞窗口是逐一增加的。
  • 快重传算法:发送方在发送了数据包之后会设置一个重发计时器,而快重传的作用就在此处使用。当接收方接收了数据包m1、m2,之后没有接收到m3,而是接收到了m4,快重传算法要求接收方立即发送对m2的重复确认,没错,这里就是m2的重复确认,可以看出来之前已经确认过了一次了,这样可以让发送方及早知道接收方没有接收到m3的数据包,发送方还会继续发送m5和m6,接收方接收到m5和m6后还要继续发送对m2的重复确认,当三次以后接收方会立即发送m3的数据包,而不用等待重发计时器的时间到来。
  • 快恢复算法:与快重传算法搭配使用的一个算法,当发生了快重传现象的时候tcp会认为网络可能没有阻塞,不然不可能连续有三个数据到达接收方,所以会将ssthresh设置为一半,而拥塞窗口设置为1,可是这里并不会进行慢开始算法,而是采用拥塞算法,缓慢增加。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,386评论 6 479
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,939评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,851评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,953评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,971评论 5 369
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,784评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,126评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,765评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,148评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,744评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,858评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,479评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,080评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,053评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,278评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,245评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,590评论 2 343

推荐阅读更多精彩内容