【计算机网络】-传输层-Internet传输协议-TCP

【计算机网络】-传输层-Internet传输协议-TCP

TCP介绍

在不可靠的互联网上提供一个可靠的端到端字节流
面向连接的、可靠的、端到端的、基于字节流的传输协议

TCP位置

1734701-20191128172638968-1391218248.png

TCP服务模型

应用程序访问TCP服务

通过在收发双方创建套接字来实现的

套接字的地址

用(IP地址,端口号)来表示的

知名端口

1024以下的端口号,如FTP:21,TELNET:23,SMTP:23

每条连接用(套接字1,套接字2)来表示,是点到点的全双工通道

TCP不支持

多播(multicast)和广播(broadcast)

TCP连接是基于字节流的,而非消息流

1734701-20191128172859505-237300244.png

(a) 按单独IP数据报发送的四个512字节的数据块

(b) 在一次READ调用中传递给应用程序的2048字节的数据

紧急数据

对于应用程序发来的数据,TCP可以立即发送,也可以缓存一段时间以便一次发送更多的数据
为了强迫数据发送,可以使用PUSH标记
对于紧急数据(urgent data),可以使用URGENT标记

序列号

TCP连接上的每个字节都有它自己独有的32位序列号

TCP协议

交换数据形式

发送端和接收段的TCP实体以数据段的形式交换数据
TCP数据段包含一个20字节的头(选项部分另加)和随后的0个或多个数据字节

段的大小要求

每个数据段包括TCP头在内,要适合IP的65515字节净荷大小
每个网络都有一个最大传输单元(MTU),每个数据段必须适合MTU。实践中,MTU通常为1500字节(以太网的净荷大小)

滑动窗口

TCP实体使用滑动窗口协议,确认序号等于接收方希望接收的下一个序号

超时重传

超时重传

TCP数据段的头

1734701-20191128173511428-476686565.png

源端口和目的端口

用于寻找发送端和接收端应用进程
各占16位

序列号

序列号表示该TCP数据段中的第一个TCP数据字节在从TCP发送端向TCP接收端发送的数据字节流中的位置。TCP用序列号对每个字节进行计数
只有SYN标志置1时序列号字段才有效
占32位,以字节为单位编号

确认号

确认号应当是上次已成功收到数据字节序号加1。只有ACK标志置1时确认号字段才有效
占32位,以字节为单位编号

TCP头长度

给出TCP头部中32位字的数目,即长度单位为32位字,包含可选项域
占4位
6位的保留域

6位的标志位:置1表示有效

URG:紧急指针有效,和紧急指针配合使用,发送紧急数据
ACK:确认号是否有效
PSH:指示接收方应该尽快将这个报文段交给应用层,不做缓存
RST:重置一个已混乱的连接
SYN:用来发起一个连接
FIN:发端完成发送任务后, FIN用于释放连接

窗口大小

  • 用于基于可变滑动窗口的流控,指示发送方从确认号开始可以再发送窗口大小的字节流,窗口大小为字节数
  • 占16位
  • 校验和
    为增加可靠性,对TCP头,TCP数据计算校验和
    占16位

紧急指针

  • 用来指示紧急数据在当前数据段中的位置,是一个相对于当前序列号的字节偏移值。当URG标志置1时紧急指针才有效
  • 占16位
  • 可选项域

TCP连接建立

1734701-20191128173853746-1788195394.png

建立过程(注:LISTEN,ACCEPT,CONNECT等就是伯克利套接字原语)
服务器方执行LISTEN和ACCEPT原语,被动监听
客户方执行CONNECT原语,产生一个SYN为1和ACK为0的TCP段,表示连接请求
服务器方的传输实体接收到这个TCP段后,首先检查是否有服务进程在所请求的端口上监听,若没有,回答RST置位的TCP段
若有服务进程在所请求的端口上监听,该服务进程可以决定是否接受该请求。在接受后,发出一个SYN置1和ACK置1的TCP段表示连接确认,并请求与对方的连接
发起方收到确认后,发出一个SYN置0和ACK置1的TCP段表示给对方的连接确认
若两个主机同时试图建立彼此间的连接,则只能建立一条连接

TCP连接释放

在数据传输结束后,通信的双方都可以发出释放连接的请求
释放过程对每个单工连接单独释放
TCP连接释放,释放连接时,发出FIN位置1的TCP段并启动定时器,在收到确认后关闭连接。若无确认并且超时,也关闭连接
1734701-20191128173948697-1127557307.png

TCP连接的管理模型

1734701-20191128174234722-359877712.png

粗实线:客户的正常路径
粗虚线:服务器的正常路径
细线:不正常的事件
事件/动作:
事件或者是用户发起的系统调用(CONNECT、LISTEN、SEND或CLOSE),或者是一个数据段的到达(SYN、FIN、ACK或RST),或者是两倍最大分组生存期的超时事件。
动作是发送一个控制数据段(SYN、FIN或RST)

TCP传输策略

1734701-20191128174348384-2065863889.png

TCP的窗口管理机制
基于确认和可变窗口大小
窗口大小为0时,正常情况下,发送方不能再发TCP段,但有两个例外,紧急数据可以发送,为防止死锁,发送方可以发送1字节的TCP段,以便让接收方重新声明确认号和窗口大小

策略1:发送方缓存应用程序的数据,等到形成一个比较大的段再发出

策略2:在没有可能进行“捎带”的情况下,接收方延迟(如:延迟500ms)发送确认段和窗口更新

策略3: Nagle算法
若数据是逐个字节地到达发送端,那么发送端就将第一个字符先发送出去,将后面到达的字符都缓存起来
当收到第一个字符的确认后,再将缓冲区中的所有字符(装成)用一个TCP数据段发送出去,同时继续对到达的字符进行缓存
只有在收到确认后才继续发送下一个数据段
如果传递进来的数据足够多,多到可以填充一半窗口或填满一个最大数据段长度时,该算法允许发送一个新的数据段

策略4:使用Clark算法解决傻窗口症状
傻窗口症状
1734701-20191128174442733-973572753.png
设想这种情况,接收端的缓冲区已满,而接收方的应用程序每次只从缓冲区中读取一个字节时,传输层实体会产生一个一字节的窗口更新段,使得发送方只能发送一个字节
解决办法
限制接收方只有在具备一半的空缓存或最大段长的空缓存时,才产生一个窗口更新段
Nagle算法和Clark针对傻窗口症状的解决方案时相互补充的
发送方不要发送太小的数据段(Nagle)
接收方不要请求太小的数据段(Clark)

TCP的拥塞控制

TCP认为导致网络拥塞的两个潜在因素
接收方接收能力
网络传输能力
1734701-20191128174545095-1340061782.png

TCP处理因接收方接收能力和网络传输能力而采取的措施
发送方维护两个窗口:接收方准许的窗口和拥塞窗口
允许发送的字节数量是这两个窗口的最小值

在TCP中使用窗口的概念

接收方准许的窗口(通知窗口)
接收方根据其能力许诺的窗口值
是来自接收端的流量控制
接收端将此窗口值放在TCP报文的头部中,传送给发送端
1734701-20191128174647105-2135315539.png

慢启动(slow start)算法

1734701-20191128175145418-1187565991.png

连接建立时,发送方将拥塞窗口初始化为该连接允许的最大数据段长(如1KB)
发出一个最大段长的TCP段,若正确确认,拥塞窗口变为两个最大数据段长
发送出2个最大长度的TCP段,若都得到确认,则拥塞窗口再加倍
重复上一步,拥塞窗口一直呈指数增加,直至发生丢包超时事件或拥塞窗口达到接收方窗口大小

因特网的拥塞控制算法

1734701-20191128175213262-1366349238.png
最大的数据段长度为1KB;
初始时阈值为64KB;
图是发生一次超时后,阈值被设置为32KB,拥塞窗口被设置为1KB(对应0号传输)

阈值初始时为64KB,当第一次超时发生时,阈值被设置为当前拥塞窗口的一半;而拥塞窗口初始化为该连接允许的最大数据段长
使用慢启动算法来决定网络的处理能力,当增长到阈值时停止
从这点开始,每次成功的传输都会使拥塞窗口线性增长

有效窗口是发送方和接收方分别认为合适窗口中最小的那个

在未发生拥塞的稳定工作状态下,两个窗口(接收方准许的窗口和拥塞窗口)是一致的

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值