吃透计算机网络(二)

运输层协议为运输在不同主机上的进程提供了逻辑通信功能。进程通过运输层的逻辑通信彼此发送报文,无须考虑承载报文的基础细节。运输层协议实在端系统中而不是在路由器中实现的。

运输层实现了不同主机上进程之间的逻辑通信,网络层提供了主机之间的逻辑通信。运输层依靠网络层(即IP),IP的服务模型是尽力而为。IP尽可能保证通信在主机之间的交付,但不做保证。即不保证报文段的交付、完整性和顺序。运输层想要保证可靠逻辑通信,必须在网络层之上多做些工作。TCP使用流量控制、序号、定时器和确认等保证正确按序的交付报文,而UDP不保证这些。

多路复用与多路分解

多路复用与多路分解是所有的计算机网络都需要的,是将网络层提供的主机到主机的交付延伸到为运行在主机上的应用程序提供的进程到进程的交付服务。

套接字是运输层与应用层之间的门户。发送端,应用程序将数据交给套接字,传输层从套接字读取数据打包成报文段并发送,接收端,传输层从报文段取出数据交给套接字,应用程序从套接字读取数据。每个套接字都有唯一的标识符,而让报文段找到它要去的套接字,需要通过报文段中前几个字段来决定。UDP套接字是由目的地址+目的端口来确认,而TCP套接字是由发送地址+发送端口+目的地址+目的端口来确认。

在接受端,运输层检查相应字段,标识出接受套接字,进而将报文段指向该套接字,将运输层报文段中的数据交付到正确的套接字称为多路分解。从源主机不同的套接字收集数据块,并为每个数据块封装上首部信息从而生成报文段,将报文段送到网络层,这些动作成为多路复用。

UDP

无连接,不可靠。
在这里插入图片描述
源端口:这个字段占据 UDP 报文头的前 16 位,通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选的,所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号,则把这个字段设置为 0。这样,接收端的应用程序就不能发送响应了。
目的端口:接收端计算机上 UDP 软件使用的端口,占据 16 位。
长度:该字段占据 16 位,表示 UDP 数据报长度,包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节,所以这个值最小为 8。
校验值:该字段占据 16 位,可以检验数据在传输过程中是否被损坏。实际上校验和除了UDP报文段还包括IP首部一些字段。

为啥UDP首部要提供检验和:
虽然很多链路层协议也提供了差错检测,但并不能保证所有的链路层都提供差错检测,所以UDP传输提供。此外,即使链路层正确传输正确,但是在路由器内存中存储时也可能出错,所以无法保证链路层可靠性。

虽然UDP能提供差错检测,但是并无错误恢复能力。当检测到错误时,可以选择丢包,也可以选择提交数据并给出警告。

TCP

TCP是面向连接的。在传输之前必须相互发送某些预备报文,以建立确保数据传输的参数。连接并不是物理上的连接,而是逻辑上的连接。TCP只会在端系统中运行,其共同状态智慧保留在两个通信段系统的TCP程序中。

TCP报文段结构

TCP报文分为首部和数据字段:
在这里插入图片描述
报文首部
源端口和目的端口(各16bit):被用于多路复用和多路分解
序号和确认号(各32bit):被用来实现可靠的数据传输服务。序号是报文段(即数据部分)首字节的字节流编号。
首部字长(4bit):表示以32bit为单位的首部字长,4bit最大为1111即60字节,典型值为0101。由于存在选项字段,TCP报文首部长度可变。不过通常选项字段为空,所以TCP首部典型长度为20字节。
标志字段(8bit):
ACK比特用于指示确认字段中的值是有效的,即该报文包括一个对已经成功连接接受报文段的确认
RST通知该端口不可连接
SYN用于TCP建立请求报文
FIN用于TCP拆除
PSH指示接收方应立即将数据交给上层
URG指示报文字段里存在着被发送段置为“紧急”的数据
CWR拥塞通告
ECE拥塞通告
接受窗口(16bit):用于流量控制,表示接收方愿意接受字节的数量。接受窗口是序号长度的一半,因为接受窗口的数量必须小于等于序号可选长度的一半。
因特网检验和(16bit):用于检测传输结果是否错误
紧急数据指针(16bit):紧急数据的最后一个字节由16bit的紧急数据指针字段指出。
选项字段(可选):用于发送方和接收方协商最大报文长度(MSS)。

报文数据

以太网最大传输单元是1500字节,减去IP头和TCP头,就是数据报允许的最大长度。典型值为1500-20(IP头)-20(TCP头)=1460.

三次握手

第一次握手:发送方SYN为1,ACK为0,随机选择初始序号A(为了防止和以前的连接相混合)。
第二次握手:接收方SYN为1,ACK为1,随机选择初始序号B,确认序号为A+1.表示已经收到连接申请,同意连接,称为SYNACK报文段。若此时分配资源(套接字、窗口变量和缓存),可能会造成SYN洪泛供给。
第三次握手:发送方SYN为0,ACK为1,序号为A+1,确认序号为B+1.此报文段可以携带数据。

SYN洪泛攻击:
如果不进行第三次握手,那么服务器将终止该半开连接并收回资源。但若攻击者发送大量的TCPSYN报文段,而不进行第三次握手,那么服务器的资源会被消耗殆尽(回收需要一定的时间,通常在1分钟之后才回收),称为SYN泛洪攻击。

SYN cookie:第二次握手时并不分配资源,而只是发送ACK。初始序列号由随机选择,变为函数计算得到。由SYN报文段的源IP、源端口、目的IP、目的端口、仅服务器知道的秘密数通过散列函数得到,服务器发送具有特殊初始序列号的SYNACK分组。若客户是合法的,那么会发送第三次握手。第三次握手报文段里的确认序号就是特殊序列号+1,服务器会再次由源IP、源端口、目的IP、目的端口、仅服务器知道的秘密数通过散列函数得到特殊序号,这个特殊序号+1应该与确认序号相同。若相同则分配资源。

若收到第一次握手,但是目的端口不支持连接,则会发送RST置1的报文段,表示此处不支持连接。
每个TCP连接中第一个报文段的ACK为0,连接重其余报文段的ACK都为1

四次挥手

TCP两端都可申请断开连接。

第一次挥手:A发送FIN为1
第二次挥手:B发送ACK
第三次挥手:B发送FIN为1
第四次挥手:A发送ACK后进入TIME_WAIT,若ACK报文丢失在这一段时间内会收到新的申请,若时间到仍未收到,表示ACK已经传达到,断开连接。

超时重传

当报文发出,但超过一定时间后还没有收到确认回复,判定为报文丢失。发送端重新发送该报文。

RTT:某报文段从被发出到对该报文段的确认被收到之间的时间段。

TCP在某一时刻仅做一次RTT测量,而不是对所有报文进行测量。没有测量状态下,有报文发送就开始测量,第一个报文发送到接受确认期间,这期间发出的报文并不测量。等收到确认回复后,又可以进行下一次测量。另外,TCP决不为重传的报文段计算RTT,仅为传输一次的报文测量RTT(假设先前的报文并未丢失,接收端也收到了,但是确认报文被拥塞堵住了,发送端未收到确认开始重传,重传之后先前的确认报文到达,这会造成测量数据不准确)。

SRTT:采样RTT
均值采样时间 ERTT = (1-a) * ERTT + a * SRTT (a一般是0.125)
采样幅度变化 DRTT = (1-b) * DRTT + b * |SRTT-DRTT| (b一般是0.25)
重传时间: T = ERTT + 4 * DRTT

初始的重传时间设置为1秒,每当出现超时之后重传时间翻倍,而不采用公式得到的时间。但是当有新的确认到达或者收到上层应用数据时,就切换回公式重新计算得到的时间。出现超时时,重传时间翻倍是为了防止网络堵塞时,重传的报文段再次超时,就会再次重传。这样会导致网络拥堵时报文段越来越多,并不利于缓解拥堵。而一旦有新确认到达,表示网络通畅,采用计算得到的时间比较合适。

定时器仅使用单一的定时器(因为定时器的开销很大,所以只用一个),即任一时刻最多只给一个报文做定时,即使发送了多个报文。TCP收到上层应用数据时,发送数据包并启动计时器,当超时出现或者接受到三个冗余ACK时重传数据报并重启计时器。当收到ACK,并且后面还有未被确认的报文,重启计时器(为后面为确认报文服务)。

快速重传

当超时周期相对较长时,报文丢失后必须等定时器时间到才会重传,增加了端到端之间的时延。当TCP接收方接受到报文后,接受需要大于期望的序号,接收方会对已经接受到的最后一个按序字节进行重复确认。当发送方收到对相同数据的3个冗余ACK,接收方认为被确认过3次的报文段之后的报文已经丢失。一旦收到三个冗余ACK,则重传丢失报文段,不等待重传计时器过期。

GBN协议(回退N步):接收方丢弃所有时序分组。发送方自未收到确认分组之后,全部重传。好处是简单,坏处是可能上一次接受但是失序的分组,下一次也出错误或丢失,造成更多的重传。

SR协议(选择重传):选择重传通过让发送方仅重传那些怀疑在接收方出错的分组,而避免了必要的重传。

TCP采用了GBN和SR的结合体。当重传时,TCP会将未收到确认报文段及以后的全部重新发送,即使后面的报文段可能已经被接收带你接受。而TCP接收端会将正确接受但是失序的报文段存储起来,等后续再接受到这个报文段时直接丢弃。

流量控制
在这里插入图片描述

流量控制和拥塞控制采取点措施非常相似,都是对发送端的遏制,但他们显然是针对不同原因而采取点措施。

流浪控制和报文段中的接受窗口字段密切相关。TCP是全双工的,服务器会为TCP连接的每一侧分配资源(套接字和缓存),当TCP接受到数据时,把它存入缓存等待应用层读取。当缓存没有时,就不能接受了。因此TCP接收方把接受窗口(当前缓存剩余多少)发送给发送方,发送方的已发送但未确认字段不能大于此。简单理解就是发送的不能比可以接受的多,防止缓存溢出。

接受方最开始的接收窗口是整个缓存的大小,接受窗口随着应用处理缓存和网络堵塞而变化。当接受窗口为0,此时发送方变不能发送数据,等待接收端缓存有位置后,接受窗口不为0,但接收方又没有需要发送段数据时,此时发送方收不到新的接受窗口数值,还以为接受窗口为0,不发送报文段。因此当发送方接受收到为0的接受窗口时,会启动坚持计时器。等到时间到后发送只有一个字节的数据报,接收方的确认报文中会有新的窗口字段。坚持计时器发送探测报文后会将时间翻倍,因为探测报文可能因为网络堵塞而丢失。

拥塞控制

可以根据网络层是否位运输层拥塞控制提供显示帮助,来区分拥塞控制的方法:

端到端到拥塞控制:网络层没有提供显示支持。TCP采用此种,TCP感觉网络的拥塞程度是通过超时或者3次冗余ACK来判断的,网络层没有提供显示的信息。

网络辅助的拥塞控制:路由器向发送方提供关于网络拥塞状态的显示反馈。某些TCP/IP也能选择性的实现网络辅助拥塞控制。

TCP发送方额外跟踪一个变量,即拥塞窗口。发送方能够发送段报文段数量<=流量窗口和拥塞窗口最小值。

TCP拥塞控制算法:
1.慢启动
2.拥塞避免
3.快速恢复

慢启动阶段:每收到一个ACK确认,拥塞窗口+1。假设所有包都正确接受,那么每过一个RTT,拥塞窗口的值应当翻倍。慢启动最开始为1,然后开始翻倍。TCP慢启动阶段发送速率起始慢,但是以指数增长。慢启动在最开始阶段,或者超时后进入慢启动。

拥塞避免阶段:当发送速率到达慢启动阈值(ssthresh)时,进入拥塞避免阶段。这一阶段每过一个RTT,发送速率增加1.

快速恢复:拥塞有两个指标超时或者3个冗余ACK。当接受到3个冗余ACK时,进入快速恢复,ssthresh设置为cwnd/2,同时发送速率设置为ssthresh(也可以是ssthresh+3)。每受到一个冗余ACK,cwnd+1。当丢失报文段的ACK到达时,cwnd设置为ssthresh,进入拥塞避免。

慢启动最开始是为了测量网络拥塞程度,然后设置慢启动阈值。而拥塞避免阶段是快到网络拥塞的速度了,所以要慢点加。拥塞有两个指标超时或者3个冗余ACK,当出现超时表示拥塞程度很严重,重新进入慢启动缓解拥塞。而3次冗余ACK表示拥塞程度不严重,最起码还有3个ACK回来了,网络还算通畅。所以只是将速度设置为ssthresh+3(或者ssthresh)。减半是要减少发送速率,缓解拥堵,+3是因为收到3次冗余ACK,表示网络中腾出3个报文段的位置。没收到一个ACK+1也是因为这样,每收到一个ACK,表示一个报文段被接受(不管是不是按照顺序),网络中就少了一个报文段传输,腾出了一个位置。

拥塞控制被概括为加性增,乘性减(AIMD)控制方法。在实践中,当多个连接同享一条链路时,具有较小RTT的连接能在空闲时更快的可用带宽,因此比较大的RTT连接享有更高的吞吐量。

需要注意拥塞控制是TCP的,但是UDP没有。因此很多媒体应用选择UDP而不是TCP,就是应为TCP有拥塞控制,但是UDP却不受限制,不想被传输速率遏制。TCP只能和TCP抢宽带,但是UDP却可以抢TCP。

UDP TCP区别

从报文结构来看,UDP报文首部是8个字节,固定的,而TCP的报文首部最少20字节,最多60字节,是可变的。
套接字识别UDP是根据目的IP+端口,而TCP是源和目的IP及端口,UDP是二元TCP是四元。
因为TCP的首部比UDP多一些,这些多的肯定是提供多的服务。比如拥塞控制、流量控制、报文可靠传输。连接控制、首部字长等等。UDP无连接即可使用,没有流量控制,也不确保数据按序完整到达,而TCP却是先连接再使用,保证数据的正确传输,提供流量控制、拥塞控制等。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值