章数据链路层

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号2.4

运输层传输流程

从通信和信息处理的角度看运输层向它上面的应用层提供通信服务它属于面向通信部分的最高层同时也是用户功能中的最低层。

当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时只有位于网络边缘部分的主机的协议栈才有运输层而网络核心部分中的路由器在转发分组时都只用到三层到网络层的功能。

“逻辑通信”是指运输层之间的通信好像是沿水平方向传送数据但事实上这两条数据并没有一条水平方向的物理连接要传送的数据是沿着图中上下多次的虚线方向传送的

进程Ap1与Ap4之间进行基于网络的通信进程Ap2与Ap3之间进行基于网络的通信

接收方的运输层通过不同的端口将收到的应用层报文交付给应用层中相应的应用进程

这里端口并不是指看得见、摸得着的物理端口而是指用来区分不同应用进程的标识符

1.2

首部中的源端口字段的值在短暂端口号49151~65535中挑选一个未被占用的用来表示DNS客户端进程

首部中的目的端口字段的值53是DNS服务器端进程所使用的熟知端口号

之后将UDP用户数据报封装在IP数据报中通过以太网发送给DNS服务器

UDP首部中的目的端口号为53这表明应将该UDP用户数据报的数据载荷部分也就是DNS查询请求报文交付给本服务器中的DNS服务器端进程

DNS服务器端进程解析DNS查询请求报文的内容然后按其要求查找对应的IP地址

之后会给用户PC发送DNS响应报文DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报

其首部中的源端口字段的值设置为熟知端口号53表明这是DNS服务器端进程所发送的UDP用户数据报目的端口的值设置为49152这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号

UDP首部中的目的端口号为49152这表明应将该UDP用户数据报的数据载荷部分也就是DNS响应报文交付给用户PC中的DNS客户端进程

DNS客户端进程解析DNS响应报文的内容就可知道自己之前所请求的Web服务器的域名对应的IP地址

现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文和DNS发送和接收流程差不多

3.1

是TCP/IP体系结构运输层中的两个重要协议当运输层采用面向连接的

TCP

协议时尽管下面的网络是不可靠的只提供尽最大努力服务但这种逻辑通信信道就相当于一条全双工的可靠信道。

当运输层采用无连接的

UDP

TCP是面向连接的TCP之间的通信必须要在两个套接字Socket之间建立连接

3.2

UDP对应用进程交下来的报文既不合并也不拆分而是保留这些报文的边界

UDP结构

使用TCP协议的通信双方在进行数据传输之前必须使用“三报文握手”建立TCP连接

TCP连接建立成功后通信双方之间就好像有一条可靠的通信信道通信双方使用这条基于TCP连接的可靠信道进行通信

发送方

TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流TCP并不知道这些待传送的字节流的含义并将他们编号并存储在自己发送缓存中TCP会根据发送策略提取一定量的字节构建TCP报文并发送

接收方

一方面从所接受到的TCP报文段中取出数据载荷部分并存储在接收缓存中一方面将接收缓存中的一些字节交付给应用进程TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块具有对应大小的关系例如发送方应用进程交给发送方的TCP共10个数据块但接收方的TCP可能只用了4个数据块就把收到的字节流交付给了上层的应用进程但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样接收方的应用进程必须有能力识别收到的字节流把它还原成有意义的应用层数据

TCP是面向字节流的这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础

本图只画了一个方向的数据流在实际网络中基于TCP连接的两端可以同时进行TCP报文段的发送和接收

TCP结构

上图主机A现在可将发送缓存中序号1~200的字节数据全部删除因为已经收到了主机B对它们的累计确认

上图主机A现在可将发送缓存中序号201~500的字节数据全部删除因为已经收到了主机B对它们的累计确认

上图主机A现在可将发送缓存中序号501~600的字节数据全部删除因为已经收到了主机B对它们的累计确认

因为零窗口探测报文段也有重传计时器重传计时器超时后零窗口探测报文段会被重传

4.2

点缓存的容量太小链路的容量不足处理机处理的速率太慢拥塞本身会进一步加剧拥塞

拥塞控制的前提网络能够承受现有的网络负荷。

实践证明拥塞控制是很难设计的因为它是一个动态问题。

分组的丢失是网络发生拥塞的征兆而不是原因。

在许多情况下甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

开环控制和闭环控制

由于缺少缓存空间而被丢弃的分组的百分数平均队列长度超时重传的分组数平均分组时延分组时延的标准差等等。

5.2

发送方给接收方发送数据报文段后接收方给发送方发发回相应的确认报文段一个传输轮次所经历的时间其实就是往返时间往返时间并非是恒定的数值使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去并受到了对已发送的最后一个报文段的确认

拥塞窗口

目的用来确定网络的负载能力或拥塞程度。

算法的思路由小到大逐渐增大拥塞窗口数值。

两个变量

拥塞窗口cwnd初始拥塞窗口值2

如果在发送过程中出现部分报文段丢失这必然会造成发送方对这些丢失报文段的超时重传

5.2.1.3

如果超时重传时间RTO的值设置得比RTT0的值小很多这会引起报文段不必要的重传使网络负荷增大

如果超时重传时间RTO的值设置得远大于RTT0的值这会使重传时间推迟的太长使网络的空闲时间增大降低传输效率

8.1

报文段。

称之为三报文握手。

采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了因而产生错误。

8.2.1

连接的建立采用客户服务器方式。

主动发起连接建立的应用进程叫做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确认报文段并进入连接已连接状态

确认位ACK被设置为1表明这是一个普通的TCP确认报文段序号字段seq被设置为x1这是因为TCP客户进程发送的第一个TCP报文段的序号为x所以TCP客户进程发送的第二个报文段的序号为x1确认号字段ack被设置为y1这是对TCP服务器进程所选择的初始序号的确认

请注意TCP规定普通的TCP确认报文段可以携带数据但如果不携带数据则不消耗序号

现在TCP双方都进入了连接已建立状态它们可以基于已建立好的TCP连接进行可靠的数据传输

为什么TCP客户进程最后还要发送一个普通的TCP确认报文段能否使用“两报文握手”建立连接

为了防止已经失效的连接请求报文段突然又传到服务端因而产生错误”这种情况是一端(client)A发出去的第一个连接请求报文并没有

丢失而是因为某些未知的原因在某个网络节点上发生滞留导致延迟到连接释放以后的某个时间才到达另一端(server)B。

本来这是一个

早已失效的报文段但是B收到此失效的报文之后会误认为是A再次发出的一个新的连接请求于是B端就向A又发出确认报文表示同

意建立连接。

如果不采用“三次握手”那么只要B端发出确认报文就会认为新的连接已经建立了但是A端并没有发出建立连接的请求因

此不会去向B端发送数据B端没有收到数据就会一直等待这样B端就会白白浪费掉很多资源。

所以并不多余这是为了防止已失效的连接请求报文段突然又传送到了TCP服务器因而导致错误

8.2.3

连接释放过程比较复杂。

数据传输结束后通信的双方都可释放连接。

TCP

8.3.1

连接的建立采用客户服务器方式。

主动发起连接建立的应用进程叫做TCP客户

(server)。

任何一方都可以在数据传送结束后发出连接释放的通知

TCP连接释放报文段首部中

终止位FIN和确认为ACK的值都被设置为1表明这是一个TCP连接释放报文段同时也对之前收到的报文段进行确认序号seq字段的值设置为u它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1确认号ack字段的值设置为v它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1

请注意TCP规定终止位FIN等于1的报文段即使不携带数据也要消耗掉一个序号

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连接的释放称为被动关闭连接

该报文段首部中

终止位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后才能进入关闭状态

TCP客户进程在发送完最后一个确认报文后为什么不直接进入关闭状态而是要进入时间等待状态

因为时间等待状态以及处于该状态2MSL时长可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态

另外TCP客户进程在发送完最后一个TCP确认报文段后在经过2MSL时长就可以使本次连接持续时间内所产生的所有报文段都从网络中消失这样就可以使下一个新的TCP连接中不会出现旧连接中的报文段

8.3.2

TCP双方已经建立了连接后来TCP客户进程所在的主机突然出现了故障

序号、确认号和确认标志位

同步标志位、终止标志位、复位标志位、推送标志位、紧急标志位和紧急指针

选项和填充