北京一家专门做会所的网站,事业单位网站设计,网站建设:中企动力,网站收录后怎么做排名目录
一、 运输层概述
二、运输层端口号、复用与分用的概念
三、UDP和TCP的对比
四、TCP的流量控制
五、TCP的拥塞控制
六、TCP超时重传时间的选择
七、TCP可靠传输的实现
八、TCP报文段的首部格式 一、 运输层概述
物理层、数据链路层、网络层实现了主机到主机的通信…目录
一、 运输层概述
二、运输层端口号、复用与分用的概念
三、UDP和TCP的对比
四、TCP的流量控制
五、TCP的拥塞控制
六、TCP超时重传时间的选择
七、TCP可靠传输的实现
八、TCP报文段的首部格式 一、 运输层概述
物理层、数据链路层、网络层实现了主机到主机的通信。 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务运输层协议又称为端到端协议。 二、运输层端口号、复用与分用的概念
发送方的复用和接收方的分用 TCP/IP体系的应用层常用协议所使用的运输层熟知端口号 三、UDP和TCP的对比
这两种协议就是本章要讨论的主要内容
用户数据报协议UDP(User Datagram Protocol)
传输控制协议TCP(Transmission Control Protocol) UDP 无连接支持一对一一对多多对一和多对多交互通信。对应用层交付的报文直接打包尽最大努力交付也就是不可靠;不使用流量控制和拥塞控制。首部开销小仅8字节 TCP 面向连接每一条TCP连接只能有两个端点EP只能是一对一通信。面向字节流可靠传输使用流量控制和拥塞控制。首部最小20字节最大60字节 四、TCP的流量控制
流量控制让发送方的发送速率不要太快要让接收方来得及接收
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。 五、TCP的拥塞控制
拥塞在某段时间若对网络中某一资源的需求超过了该资源所能提供的可用部分网络性能就要变坏的情况拥塞窗口cwnd发送方维护的状态变量其值取决于网络的拥塞程度并且动态变化。冂
拥塞窗口cwnd的维护原则:只要网络没有出现拥塞拥塞窗口就再增大一些;但只要网络出现拥塞拥塞窗口就减少
一些判断出现网络拥塞的依据:没有按时收到应当到达的确认报文(即发生超时重传) 发送方将拥塞窗口作为发送窗口swnd即swndcwnd
维护一个慢开始门限ssthresh状态变量 “慢开始”是指一开始向网络注入的报文段少并不是指拥塞窗口cwnd增长速度慢; “拥塞避免”并非指完全能够避免拥塞而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长使网络比较不容易出现拥塞; 有时个别报文段会在网络中丢失但实际上网络并未发生拥塞这将导致发送方超时重传并误认为网络发生了拥塞会降低了传输效率。 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失就是使发送方尽快进行重传而不是等超时重传计时器超时再重传 要求接收方不要等待自己发送数据时才进行捎带确认而是要立即发送确认即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认发送方一旦收到3个连续的重复确认就将相应的报文段立即重传而不是等该报文段的超时重传计时器超时再重传 发送方一旦收到3个重复确认就知道现在只是丢失了个别的报文段。于是执行快恢复算法 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。 六、TCP超时重传时间的选择
RFC6298建议使用下式计算超时重传时间RTO 针对出现超时重传时无法测准往返时间RTT的问题Karn提出了一个算法:出现重传时不重新计算RTTS 这又引起了新的问题。设想出现这样的情况:报文段的时延突然增大了很多并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内不会收到确认报文段。于是就重传报文段。但根据Karn算法不考虑重传的报文段的往返时间样本。这样超时重传时间就无法更新。这会导致报文段反复被重传。 因此要对Karn算法进行修正。方法是:报文段每重传一次就把超时重传时间RTO增大一些。 典型的做法是将新RTO的值取为旧RTO值的2倍。 TCP基于以字节为单位的滑动窗口来实现可靠传输 TCP基于以字节为单位的滑动窗口来实现可靠传输。
发送方在未收到接收方的确认时可将发送窗口内还未发送的数据全部发送出去:接收方只接收序号落入发送窗口内的数据;
虽然发送方的发送窗口是根据接收方的接收窗口设置的但在同一时刻发送方的发送窗口并不总是和接收方的接收窗口一样大。
网络传送窗口值需要经历一定的时间滞后并且这个时间还是不确定的发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。 对于不按序到达的数据应如何处理TCP并无明确规定。
如果接收方把不按序到达的数据一律丢弃那么接收窗口的管理将会比较简单但这样做对网络资源的利用不利因为发送方会重复传送较多的数据。TCP通常对不按序到达的数据是先临时存放在接收窗口中等到字节流中所缺少的字节收到后再按序交付上层的应用进程 TCP要求接收方必须有累积确认和捎带确认机制这样可以减小传输开销。接收方可以在合适的时候发送确认也可以在自己有数据要发送时把确认信息顺便捎带上。
接收方不应过分推迟发送确认否则会导致发送方不必要的超时重传这反而浪费了网络的资源。TCP标准规定确认推迟的时间不应超过0.5秒若收到一连串具有最大长度的报文段则必须每隔一个报文段就发送一个确认[RFC 1122].捎带确认实际上井不经常发生因为大多数应用程序很少同时在两个方向上发送数据。 TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段因此每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时-定要弄清楚是哪一方的窗口 七、TCP可靠传输的实现 TCP的连接建立要解决以下三个问题:
使TCP双方能够确知对方的存在;使TCP双方能够协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。 TCP使用“三报文握手”建立连接 最后一次握手是否多余 不多余 这是为了防止已失效的连接请求报文段突然又传送到了TCP服务器因而导致错误 TCP通过“四报文挥手”来释放连接 MSL(Maximum Segment Lifetime)意思是最长报文段寿命RFC793建议为2分钟 发送方最后一次等待有必要吗 有必要 客户端出现故障服务器端如何发现 TCP服务器进程每收到一次TCP客户进程的数据就重新设置并启动保活计时器(2小时定时) 若保活计时器定时周期内未收到TCP客户进程发来的数据则当保活计时器到时后TCP服务器进程就向TCP客户进程发送一个探测报文段以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应TCP服务器进程就认为TCP客户进程所在主机出了故障接着就关闭这个连接。 八、TCP报文段的首部格式 源端口:占16比特写入源端口号用来标识发送该TCP报文段的应用进程 目的端口:占16比特写入目的端口号用来标识接收该TCP报文段的应用进程 序号:占32比特取值范围[0,2”1]序号增加到最后一个后下一个号就又回到0。指出本TCP报文段数据载荷的第一个字节的序号 确认号:占32比特确认号增加到最后一个后下一个确认号就又回到0 指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号同时也是对之前收到的所有数据的确认 确认标志位ACK:取值为1时确认号字段才有效;取值为0时确认号字段无效TCP规定在连接建立后所有传送的TGP报文段都必须把AGK置1。) 数据偏移:占4比特并以4字节为单位。 用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远这个字段实际上是指出了TGP报文段的首部长度。 首部固定长度为20字节因此数据偏移字段的最小值为(0101)2 首部最大长度为60字节因此数据偏移字段的最大值为(1111)2 保留:占6比特保留为今后使用但目前应置为0 窗口:占16比特以字节为单位。指出发送本报文段的一方的接收窗口 校验和:占16比特检查范围包括TCP报文段的首部和数据载荷两部分在计算校验和时要在TCP报文段的前面加上12字节的伪首部。 同步标志位SYN:在TCP连接建立时用来同步序号。 终止标志位FIN:用来释放TCP连接 复位标志位RST:用来复位TCP连接。 当RST1时表明TGP连接出现了异常必须释放连接然后再重新建立连接RST置1还用来拒绝一个非法的报文段或拒绝打开一个TGP连接 推送标志位PSH:接收方的TCP收到该标志位为1的报文段会尽快上交应用进程而不必等到接收缓存都填满后再向上交付。 紧急标志位URG:取值为1时紧急指针字段有效;取值为0时紧急指针字段无效。紧急指针:占16比特以字节为单位用来指明紧急数据的长度。 填充:由于选项的长度可变因此使用填充来确保报文段首部能被4整除(因为数据偏移字段也就是首部长度字段是以4字节为单位的)
