对单位网站的要求吗,视频生成网址链接,动漫制作专业有哪些课程,广州效果图设计公司5.1、运输层概述
概念 进程之间的通信 从通信和信息处理的角度看#xff0c;运输层向它上面的应用层提供通信服务#xff0c;它属于面向通信部分的最高层#xff0c;同时也是用户功能中的最低层。 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时…5.1、运输层概述
概念 进程之间的通信 从通信和信息处理的角度看运输层向它上面的应用层提供通信服务它属于面向通信部分的最高层同时也是用户功能中的最低层。 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时只有位于网络边缘部分的主机的协议栈才有运输层而网络核心部分中的路由器在转发分组时都只用到三层到网络层的功能。
进程之间通信流程 以上图为例进程Ap1与Ap4之间以及进程Ap2与Ap3之间进行基于网络的通信。它们在运输层使用不同的端口来对应不同的应用进程。然后通过网络层及其下层来传输应用层报文。接收方的运输层通过不同的端口将收到的应用层报文交付给应用层中相应的应用进程。
注意此处运输层的端口是区分不同应用进程的标识符而非物理端口。
逻辑通信运输层之间的通信好像是沿水平方向传送数据但事实上这两条数据并没有一条水平方向的物理连接要传送的数据是沿着图中上下多次的虚线方向传送的
总结 5.2、运输层端口号、复用与分用的概念
为什么用端口号
IANA因特网数字分配机构
发送方的复用和接收方的分用 发送方的某些应用程序所发送的不同应用报文在运输层使用UDP协议进行封装称为UDP复用使用TCP协议进行封装称为TCP复用。运输层使用不同的端口号区分不同的进程。无论是UDP协议封装的UDP用户数据段还是TCP协议封装的TCP报文段它们都会在网络层使用IP协议封装成IP数据报而这称为IP复用。 接收方的网络层收到发送方的IP数据报后进行IP分用如果该IP数据报首部中协议字段的值为17则把IP数据报的数据载荷部分所封装的UDP用户数据报上交运输层的UDP如果该IP数据报首部中协议字段的值为6则把IP数据报的数据载荷部分所封装的TCP报文段上交运输层的TCP。运输层对UDP用户数据报进行UDP分用对TCP报文段进行TCP分用将它们交付给上层相应的应用进程 注意IP数据报首部中协议字段的值用来表明IP数据报的数据载荷部分封装的是何种协议数据单元值为6表明封装TCP报文段值为17表明封装UDP用户数据段 TCP/IP体系的应用层常用协议所使用的运输层熟知端口号 运输层传输流程 如图所示以上主机通过交换器互连并处于同一个以太网中 现我们在用户PC中使用浏览器访问web服务器输入域名回车浏览。用户PC中的DNS客户端进程会发送一个DNS查询请求报文。该报文需要使用运输层的UDP协议封装成UDP用户数据报其首部中的源端口字段的值在短暂端口号49151~65535中挑选一个未被占用的此处使用49152用来表示DNS客户端进程目的端口字段的值为53是DNS服务器端进程所使用的熟知端口号。 之后将UDP用户数据报封装在IP数据报中通过以太网发送给DNS服务器 DNS服务器收到该IP数据报后从中解封出UDP用户数据报。UDP首部中的目的端口号为53这表明应将该UDP用户数据报的数据载荷部分也就是DNS查询请求报文交付给本服务器中的DNS服务器端进程。 DNS服务器端进程解析DNS查询请求报文的内容然后按其要求查找对应的IP地址。之后DNS服务器会给用户PC发送DNS响应报文DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报。 其首部中的源端口字段的值设置为熟知端口号53表明这是DNS服务器端进程所发送的UDP用户数据报目的端口的值设置为49152这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号。 DNS服务器将UDP用户数据报封装在IP数据报中通过以太网发送给用户PC 用户PC收到该数据报后从中解封出UDP用户数据报。UDP首部中的目的端口号为49152这表明应将该UDP用户数据报的数据载荷部分也就是DNS响应报文交付给用户PC中的DNS客户端进程。DNS客户端进程解析DNS响应报文的内容就可知道自己之前所请求的Web服务器的域名对应的IP地址 现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文。
HTTP请求报文需要使用运输层的TCP协议封装成TCP报文段其首部中的源端口字段的值短暂端口号49151~65535中挑选一个未被占用的此处使用49152用来表示HTTP客户端进程目的端口字段的值为80是HTTP服务器端进程所使用的熟知端口号。 之后将TCP报文段封装在IP数据报中通过以太网发送给Web服务器 DWeb服务器收到该IP数据报后从中解封出TCP用户数据报TCP首部中的目的端口号为80这表明应将该TCP报文段的数据载荷部分也就是HTTP请求报文交付给本服务器中的HTTP服务器端进程。
HTTP服务器端进程解析HTTP请求报文的内容然后按其要求查找首页内容。之后Web服务器会给用户PC发送HTTP响应报文其内容是HTTP客户端所请求的首页内容。HTTP响应报文需要使用运输层的TCP协议封装成TCP报文段。 其首部中的源端口字段的值设置为熟知端口号80表明这是DNS服务器端进程所发送的TCP用户数据报目的端口的值设置为49152这是之前用户PC中发送HTTP请求报文的HTTP客户端进程所使用的短暂端口号。 之后将TCP报文段封装在IP数据报中通过以太网发送给用户PC 用户PC收到该数据报后从中解封出TCP报文段。TCP首部中的目的端口号为49152这表明应将该TCP报文段的数据载荷部分也就是HTTP响应报文交付给用户PC中的HTTP客户端进程。HTTP客户端进程解析HTTP响应报文的内容并在网页浏览器中进行显示。这样我们就可以在网页浏览器中看到Web服务器所提供的首页内容了
5.3、UDP和TCP的对比
概念 UDP 和 TCP 是TCP/IP体系结构运输层中的两个重要协议 当运输层采用面向连接的 TCP 协议时尽管下面的网络是不可靠的只提供尽最大努力服务但这种逻辑通信信道就相当于一条全双工的可靠信道。 当运输层采用无连接的 UDP 协议时这种逻辑通信信道是一条不可靠信道。
可靠信道与不可靠信道 两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。 TCP 传送的数据单位协议是 TCP 报文段(segment)。 UDP 传送的数据单位协议是 UDP 报文或用户数据报。 使用UDP协议的双方可以随时发送数据。
三报文握手和四报文挥手属于TCP的连接管理实现较为复杂。
UDP的通信是无连接的不需要套接字Socket
TCP是面向连接的TCP之间的通信必须要在两个套接字Socket之间建立连接
注意此处的连接依然是指逻辑连接关系而非物理连接
用户数据报协议UDPUser Datagram Protocol 其中任何一台主机都可以向其他三台主机发送广播也可以向某个多播组发送多播还可以发送单播也就是说UDP支持一对一一对多以及一对全的通信 发送方的应用进程将应用层报文交付给运输层的UDPUDP给每个应用层报文添加一个UDP首部使之成为UDP用户数据报然后发送。接收方的UDP收到UDP用户数据报后去掉UDP首部将应用层报文交付给应用进程
UDP对应用进程交下来的报文既不合并也不拆分而是保留这些报文的边界。换句话说UDP是面向应用报文 发送方给接收方发送UDP用户数据报若传输过程中用户数据报受到干扰而产生误码接收方UDP可以通过该数据报首部中的校验和字段的值检查出产生误码的情况并丢失该数据报。
发送方给接收方发送UDP用户数据报如果该数据报被因特网中的某个路由器丢弃了发送方UDP不做任何处理 传输控制协议TCPTransmission Control Protocol 使用TCP协议的通信双方在进行数据传输之前必须使用三报文握手建立TCP连接 TCP连接建立成功后通信双方之间就好像有一条可靠的通信信道通信双方使用这条基于TCP连接的可靠信道进行通信
很显然TCP仅支持单播也就是一对一的通信 发送方 TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流TCP并不知道这些待传送的字节流的含义仅将他们编号并存储在自己发送缓存中TCP会根据发送策略从发送缓存中提取一定量的字节构建TCP报文并发送 接收方 TCP一方面从所接收到的TCP报文段中取出数据载荷部分并存储在接收缓存中一方面将接收缓存中的一些字节交付给应用进程 TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块具有对应大小的关系例如发送方应用进程交给发送方的TCP共10个小数据块但接收方的TCP可能只用了4个大数据块就把收到的字节流交付给了上层的应用进程但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样 接收方的应用进程必须有能力识别收到的字节流把它还原成有意义的应用层数据 TCP是面向字节流的这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础 本图只画了一个方向的数据流在实际网络中基于TCP连接的两端可以同时进行TCP报文段的发送和接收 使用TCP连接的双方基于TCP连接的可靠通道使用数据传输不会出现误码丢失乱序以及重复等传输差错
TCP结构
总结 5.4、TCP的流量控制
概念
假设主机a发送的每100字节数据都封装成TCP报文段b的接收窗口为400个字节数据因此主机a的发送窗口也设置为400。主机a在未收到主机b发来的确认时可将落入发送窗口中的全部数据发送出去
seq是tcp报文段首部中的序号字段取值值为1表示tcp报文段数据载荷第一个字节序号为1。
date表示该数据是tcp数据报文段。
ACK表示tcp报文段首部中的标志位值为1表示这是一个tcp确认报文段。。
ack表示tcp报文段首部中的确认号字段值为201表示序号201之前的数据已全部接收先希望收到序号201及其后续数据。
rwnd是报文段首部中的窗口字段取值300表示自己的接收窗口大小为300
流量控制是根据网络波动调节的 由于主机b在该累计确认中已将自己的接收窗口调整了300因此主机a相应的把自己的发送窗口也调整为300。 主机a收到201之前的数据的累计确认后将发送窗口向前滑动使已发送并收到确认的这些数据的序号移除发送窗口并将1~200的字节数据全部删除。
在上图中201-300是已发送数据当重传计时器超时它们仍会被重传。
当201-500的重传计时器超时时主机a将其重新封装成一个TCP报文段发送出去暂时不能发送新数据 在上图的最后主机b向主机a发送零窗口通知 为解决该问题TCP为每一个连接设置一个持续计时器。 如上图所示主机a收到了收到主机b的零窗口通知就启动持续计时器。当持续计时器超时主机a发送一个零窗口探测报文主机b收到探测报文段后发送包含其接收窗口值的确认报文。如果该值仍为0主机a收到该报文段重新启动持续计时器。如果该值不为0则打破死锁的局面
主机a发送的零窗口探测报文段后启动重传计时器。当零窗口探测报文段丢失后主机b无法收到该报文因此主机a也无法收到确认报文此时重传计时器就会超时零窗口探测报文段会被重传
注意TCP规定即使接收窗口为0主机也必须接收零窗口探测报文段确认报文段以及携带紧急数据的报文段
习题 主机甲收到确认后先滑动发送窗口再调整发送窗口
总结 5.5、TCP的拥塞控制
概念
理想的拥塞控制当输入负载达到某一限度时由于网络资源受限吞吐量不再增长达到饱和。此时加大输入负载则会损失数据
无拥塞控制在未达到吞吐量饱和前就有部分输入分组被丢弃。当网络吞吐量明显小于理想吞吐量时网络进入轻度拥塞状态。当输入负载达到某一数值时网络吞吐量随输入负载增大而降低进入拥塞状态直到死锁
网络拥塞往往是由许多因素引起的
1.点缓存的容量太小
2.链路的容量不足
3.处理机处理的速率太慢
4.拥塞本身会进一步加剧拥塞
拥塞控制的一般原理
1.拥塞控制的前提网络能够承受现有的网络负荷。
2.实践证明拥塞控制是很难设计的因为它是一个动态问题。
3.分组的丢失是网络发生拥塞的征兆而不是原因。
4.在许多情况下甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。
开环控制和闭环控制
监测网络的拥塞
主要指标有
1.由于缺少缓存空间而被丢弃的分组的百分数
2.平均队列长度
3.超时重传的分组数
4.平均分组时延
5.分组时延的标准差
上述这些指标的上升都标志着拥塞的增长。
拥塞控制的算法 真正的发送窗口值 Min (接收方窗口值拥塞窗口值) 传输轮次
1.发送方给接收方发送数据报文段后接收方给发送方发发回相应的确认报文段
2.一个传输轮次所经历的时间其实就是往返时间往返时间并非是恒定的数值
3.使用传输轮次是为了强调拥塞窗口把允许发送的报文段都连续发送出去并收到了对已发送的最后一个报文段的确认
拥塞窗口cwnd
1.初始拥塞窗口值2 种设置方法窗口值逐渐增大。
2 至 4 个最大报文段 RFC 56811 至 2 个最大报文段 旧标准
2.拥塞窗口会随网络拥塞程度以及所使用的拥塞控制算法动态变化
3.拥塞窗口值是多少发送方就可以发送多少个数据报文段
慢开始门限ssthresh防止拥塞窗口增长过大引起网络拥塞。
接下来我们将以一个完整的数据传输过程来讲解慢开始和拥塞避免算法
慢开始slow-start
目的用来确定网络的负载能力或拥塞程度。
算法的思路由小到大逐渐增大拥塞窗口数值。发送方每收到一个新报文段的确认拥塞窗口值加一然后开始下一轮的传输。 接下来我们将举一个具体的例子在本例中发送方初始拥塞窗口值为1
如上图所示发送方收到了一个确认报文因此拥塞窗口加一 经过四个传输轮次后拥塞窗口值等于慢开始门限值开始拥塞避免算法
拥塞避免congestion avoidance 思路让拥塞窗口 cwnd 缓慢地增大避免出现拥塞。 每经过一个传输轮次拥塞窗口加一使拥塞窗口 cwnd 按线性规律缓慢增长。 在拥塞避免阶段具有 “加法增大” (Additive Increase) 的特点。 如图所示每经过一次传输轮次后拥塞窗口就会加一 如果在发送过程中出现部分报文段丢失这必然会造成发送方对这些丢失报文段的超时重传 此时重新从慢开始算法开始并将慢开始门限值调整为了发送拥塞时拥塞窗口的一半 当拥塞窗口值等于慢开始门限值时开始拥塞避免算法
两个算法完整示意图
快重传和快恢复
快重传fast retrasmit
如上图所示接收方发现自己接收到的报文段M4不是依序达到的报文段时就会 向发送方再次发送重复确认报文段M3以告诉发送方发送丢失的报文段。当该行为连续发生三次以后发送方就会立刻重传丢失的报文段M3。当接收方收到丢失的报文段M3时发送最后接收到的报文段M6的确认报文段以告知发送方报文段M6之前的报文段已正常接收。此时便不会造成发送方对M3的超时重传了
快恢复fast recovery
改进后的整体算法的示意图
习题 5.6、TCP超时重传时间的选择
如果超时重传时间RTO的值设置得比RTT0的值小很多这可能会造成发送方未收到确认报文段时超时重传器就超时了然后发生不必要的重传使网络负荷增大 如果超时重传时间RTO的值设置得远大于RTT0的值这会使重传时间推迟的太长使网络的空闲时间增大降低传输效率
TCP可以通过某次测量的RTT计算出一个相对合理的RTO 由于TCP下层是复杂的互联网环境因此每次数据传输的RTT都可能不同单次RTT计算得出的RTP可能并不准确这会造成发送方不必要的超时重传所以TCP会根据每次的RTT计算更新RTP RFC6298建议使用下式计算超时重传时间RTO
往返时间RTT的测量比较复杂
TCP超时重传的计算 总结 5.7、TCP可靠传输的实现
本节以一个具体的例子去描述TCP可靠传输的实现 不推荐的原因发送方在收到向后收缩的通知前可能发送了窗口中的很多数据此时在收缩窗口不允许发送这些数据就会发送错误
比如发送方在收到收缩通知时已经发送了31-41的数据但未收到确认报文并且发送窗口位置也没有改变此时将窗口调整到了31-35就会发生错误无法描述发送窗口的状态 因此TCP使用了三个指针P1,P2,P3分别指向相应的字节序号通过相关计算便可确认发送窗口的状态了 发送方向接收方发送31-41的报文段由于31报文段各种异常原因接收方首先收到了32-33的报文段由于该报文段落在接收窗口所以接收方依然将其存入接收缓存中。 由于接收方只能对按序到达的报文段发送确认报文因此接收方向发送方发送31号确认报文。当发送方收到31号的重复确认时就知道接收方收到了未按序达到的数据。由于这是第一次重复确认因此不会引起快重传
注意运输层的ack表示希望收到的报文段而非数据链路层的ack 此时接收方收到了发送方发送的数据报文段31将其存入接收缓存。接收方将31-33的数据报文段交付给应用进程并移动三个接收窗口 现在接收方收到了37,38,40的数据报文段并发送给发送方确认报文段虽然37,38,40落在接收窗口但它们都是未按序到达的数据只能暂存在接收缓存中 此时发送方收到确认报文 此时发送方又发送了42-53的报文段发送窗口数据发送 完毕。 习题 5.8、TCP的运输连接管理
概念
TCP的连接建立 TCP 建立连接的过程叫做握手。 握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手。 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了因而产生错误。
TCP的连接建立要解决以下三个问题
TCP使用“三报文握手”建立连接 TCP 连接的建立采用客户服务器方式。 主动发起连接建立的应用进程叫做TCP客户 (client)。 被动等待连接建立的应用进程叫做TCP服务器 (server)。
握手需要在TCP客户端和服务器之间交换三个TCP报文段
如下为三次握手的过程
最初两端的TCP进程都处于关闭状态 TCP服务器首先建立传输控制块用来存储TCP连接中的一些重要信息之后进入监听状态被动等待客户端进程的连接请求
TCP服务器进程被动发起TCP连接建立的过程称为被动动打开连接
注意TCP客户进程也是先创建传输控制块后建立TCP连接
当TCP客户进程向TCP服务器进程主动发送TCP连接请求报文段时进入同步已发送状态。
TCP客户进程主动发起TCP连接建立的过程称为主动打开连接 TCP连接请求报文段首部中 同步位SYN被设置为1表明这是一个TCP连接请求报文段 序号字段seq被设置了一个初始值x作为TCP客户端进程所选择的初始序号 请注意TCP规定SYN被设置为1的报文段不能携带数据但要消耗掉一个序号 TCP服务器进程收到TCP连接请求报文段后如果同意建立连接则向TCP客户进程发送TCP连接请求确认报文段并进入同步已接收状态 TCP连接请求确认报文段首部中 同步位SYN和确认位ACK都设置为1表明这是一个TCP连接请求确认报文段 序号字段seq被设置了一个初始值y作为TCP服务器进程所选择的初始序号 确认号字段ack的值被设置成了x1这是对TCP客户进程所选择的初始序号seq的确认 请注意这个报文段也不能携带数据因为它是SYN被设置为1的报文段但同样要消耗掉一个序号 TCP客户进程收到TCP连接请求确认报文段后还要向TCP服务器进程发送一个普通的TCP确认报文段并进入连接已建立状态 普通的TCP确认报文段首部中 确认位ACK被设置为1表明这是一个普通的TCP确认报文段 序号字段seq被设置为x1这是因为TCP客户进程发送的第一个TCP报文段的序号为x所以TCP客户进程发送的第二个报文段的序号为x1 确认号字段ack被设置为y1这是对TCP服务器进程所选择的初始序号的确认 请注意TCP规定普通的TCP确认报文段可以携带数据但如果不携带数据则不消耗序号 TCP服务器进程收到该确认报文段后也进入连接已建立状态 现在TCP双方都进入了连接已建立状态它们可以基于已建立好的TCP连接进行可靠的数据传输 三报文握手是否多余我们通过一个“两报文握手”实例进行观察 当TCP客户进程发送一个TCP连接请求报文段后该报文段由于各种原因导致在某网络节点长时间滞留此时TCP客户进程对该报文段超时重传。 TCP服务进程正常接收新的报文段并向TCP客户进程发送TCP确认报文段之后进入连接已建立状态。 TCP客户进程收到TCP确认报文段后进入TCP连接已建立状态。 此时客户进程和服务器进程可以进行数据传输之后通过四报文挥手释放连接并进入关闭状态。 一段时间以后原本滞留的TCP连接请求报文段到达TCP服务器进程TCP服务器进程会错误的再次进入连接已建立状态并向TCP客户进程发送TCP确认报文段但TCP客户进程并不理睬因此这必然造成服务器进程的资源浪费 因此三报文握手是为了防止已失效的连接请求报文段突然又传送到了TCP服务器因而导致错误 习题 总结
TCP的连接释放 TCP 连接释放过程比较复杂。 数据传输结束后通信的双方都可释放连接。 TCP 连接释放过程是四报文握手。
TCP通过“四报文挥手”来释放连接 TCP 连接的建立采用客户服务器方式。 主动发起连接建立的应用进程叫做TCP客户 (client)。 被动等待连接建立的应用进程叫做TCP服务器 (server)。 任何一方都可以在数据传送结束后发出连接释放的通知
过程 现在TCP客户进程和TCP服务器进程都处于连接已建立状态 TCP客户进程的应用进程通知其主动关闭TCP连接TCP客户进程会发送TCP连接释放报文段并进入终止等待1状态 TCP连接释放报文段首部中 终止位FIN和确认为ACK的值都被设置为1表明这是一个TCP连接释放报文段同时也对之前收到的报文段进行确认 序号seq字段的值设置为u它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1 确认号ack字段的值设置为v它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1 请注意TCP规定终止位FIN等于1的报文段即使不携带数据也要消耗掉一个序号 TCP服务器进程收到TCP连接释放报文段后会发送一个普通的TCP确认报文段并进入关闭等待状态 普通的TCP确认报文段首部中 确认位ACK的值被设置为1表明这是一个普通的TCP确认报文段 序号seq字段的值设置为v它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1这也与之前收到的TCP连接释放报文段中的确认号匹配 确认号ack字段的值设置为u1这是对TCP连接释放报文段的确认 TCP服务器进程通知高层应用进程TCP客户进程要断开与自己的TCP连接。这时从TCP客户进程到TCP服务器进程这个方向的连接就释放了此时TCP连接属于半关闭状态也就是TCP客户进程已经没有数据要发送了该状态可能持续一段时间。 但如果TCP服务器进程还有数据要发送TCP客户进程仍要接收也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭 TCP客户进程收到TCP确认报文段后就进入终止等待2状态等待TCP服务器进程发出的TCP连接释放报文段 若使用TCP服务器进程的应用进程已经没有数据要发送了应用进程就通知其TCP服务器进程释放连接 由于TCP连接释放是由TCP客户进程主动发起的因此TCP服务器进程对TCP连接的释放称为被动关闭连接 TCP服务器进程发送TCP连接释放报文段并进入最后确认状态 该报文段首部中 终止位FIN和确认位ACK的值都被设置为1表明这是一个TCP连接释放报文段同时也对之前收到的报文段进行确认 序号seq字段的值为w这是因为在半关闭状态下TCP服务器进程可能又发送一些数据 确认号ack字段的值为u1这是对之前收到的TCP连接释放报文段的重复确认 TCP客户进程收到TCP连接释放报文段后必须针对该报文段发送普通的TCP确认报文段之后进入时间等待状态 该报文段首部中 确认为ACK的值被设置为1表明这是一个普通的TCP确认报文段 序号seq字段的值设置为u1这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据但要消耗掉一个序号 确认号ack字段的值设置为w1这是对所收到的TCP连接释放报文段的确认 TCP服务器进程收到该报文段后就进入关闭状态而TCP客户进程还要进过2MSL后才能进入关闭状态 2MSL时长的时间等待里TCP客户端没有收到来自TCP服务器进程的确认报文段就说明TCP服务器收到了TCP确认报文段而没有超时重发并且在2MSL时间后本次连接释放而存在的报文段全部消失不再影响下一次连接释放 如果TCP客户进程没有时间等待而直接处于关闭状态TCP服务器进程就会因为迟迟收不到确认报文段而超时重发无法进入CLOSE状态因此时间等待很有必要 TCP保活计时器的作用
TCP双方已经建立了连接后来TCP客户进程所在的主机突然出现了故障此时TCP服务器进程以后就不能再收到TCP客户进程发来的数据因此应当有措施使TCP服务器进程不要再白白等待下去 5.9、TCP报文段的首部格式
各字段的作用
源端口和目的端口 接下来我们以一个例子演示TCP报文段源端口和目的端口的作用 如上图所示主机中浏览器进程浏览一个网页时首先构建一个封装有HTTP请求报文的TCP报文段并将其发送
注意使用HTTP协议的Web服务器进程默认80端口 Web服务器收到该TCP报文段后解封出HTTP请求报文并根据TCP报文段首部中目的端口字段80将HTTP请求报文上交给Web服务器进程。Web服务器进程根据HTTP请求报文的内容进行相应的处理并构建HTTP相应报文然后封装为TCP报文段进行发送 主机收到该TCP报文段后解封出HTTP响应报文并根据TCP报文段首部中目的端口字段49152将其上交给浏览器进程。浏览器进程对HTTP响应保温杯的内容进行解析并显示
序号、确认号和确认标志位 接下来我们以一个例子演示TCP报文段序号、确认号和确认标志位的作用 数据偏移、保留、窗口和校验和 注意发送窗口的大小还取决于拥塞窗口的大小。发送窗口的大小从接收窗口和拥塞窗口中取小者 同步标志位、终止标志位、复位标志位、推送标志位、紧急标志位和紧急指针 前者SYN表明这是一个TCP连接请求报文段后者SYN表面这是TCP连接请求确认报文段 前者FIN表明这是一个TCP连接释放报文段后者FIN表面这是TCP连接释放确认报文段 接收方收到紧急标志为1的报文段会按照紧急指针的值从报文段数据载荷部分取出紧急数据并直接上交应用进程而不必在接收缓存中排队
选项和填充 注意 增加选项可以增加TCP的功能
