计算机网络 笔记 2020.08.24.md
-----: | :--: | :----: | :--: | :--: | :--: | :--: | :--: | :---: | :--------: |
| 熟知端口号 | 21 | 23 | 25 | 53 | 69 | 80 | 161 | 443 | 162 |
5.2 用户数据报协议UDP
5.2.1 UDP概述
用户数据报协议UDP只在IP数据报服务之上增加了复用和分用(也就是端口功能)及差错检验功能。
特点:
- UDP是无连接的
- UDP使用尽最大努力交付,即不保证可靠交付
- UDP是面向报文的,将应用层交下来的报文照样发送,也就是一次交付一个完整的报文
- UDP没有拥塞控制
- UDP支持一对一,一对多,多对一和多对多的交互通信
- UDP首部开销小
5.2.2 UDP的首部格式
用户数据报 UDP 有两个字段:数据字段和首部字段。首部字段有 8 个字节,由 4 个字段组成,每个字段都是两个字节。
- 源端口
- 目的端口
- 长度
- 校验和
UDP用户数据报之前增加12字节的伪首部,在计算检验和时,临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。
5.3 传输控协议TCP概述
5.3.1 TCP的主要特点
- TCP是面向连接的运输层协议
- 每一条 TCP 连接只能有两个端点(endpoint),每一条 TCP 连接只能是点对点的(一对一)。
- TCP 提供可靠交付的服务。
- TCP 提供全双工通信。
- 面向字节流。
TCP与应用程序的交互是一次一个数据块(大小不定),TCP将应用程序交下来的数据看成是一连串的无结构的字节流,并且TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系,但是接收方应用程序收到的字节流必须与发送的一致。也就是过程中的数据分块可以多样,但是最终的结果是传输数据完整一致。
注意:
- TCP 连接是一条虚连接而不是一条真正的物理连接。
- TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。
- TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP 发送的报文长度是应用进程给出的)。
- TCP 可把太长的数据块划分短一些再传送。TCP也可等待积累有足够多的字节后再构成报文段发送出去。
5.3.2 TCP 的连接
TCP 把连接作为最基本的抽象,每一条 TCP 连接有两个端点。TCP 连接的端点叫做套接字(socket)或插口。
端口号拼接到(contatenated with) IP 地址即构成了套接字。每一条 TCP 连接唯一地被通信两端的两个端点(即两个套接字)所确定。
套接字 (socket):
5.4 可靠传输的工作原理
5.4.1 停止等待协议
在全双工通信时双方既是发送方也是接收方,这里我们仅考虑A发送数据B接收数据,因此A为发送方,B为接收方。
无差错情况
A向B发送M1,发送完停止发送,B收到M1就向A发送确认,A收到确认继续发送M2,同样收到B的确认后发送M3,如此往复。
出现差错
当A发送M1之后,B收到M1后检验出现错误而丢弃了M1(但是没有通知A收到有差错数据),A超过一段时间没有收到确认,就会重新传M1,这就是超时重传,实现超时重传用到了超时计时器。
注意:
- A发送完分组后,必须暂时保留已发送分组的副本
- 分组和确认分组应进行编号
- 超时计时器应该比平均往返时间长一些
确认丢失
当B向A发送的对M1的确认丢失了,A在超时计时器到期后未收到M1的确认,于是A会重传M1,此时B收到M1后,会丢弃重复的这个M1,然后再次向A发送M1的确认。
确认迟到
同样B收到M1后发送M1的确认,但是M1因为网络等等原因并未及时被A收到,这时A有重传了M1,B收到后同样是丢弃重复的M1并再次发送M1的确认。
使用上述的确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信。*这种可靠传输协议常称为*自动重传请求ARQ (Automatic Repeat reQuest)。ARQ 表明重传的请求是自动**进行的。接收方不需要请求发送方重传某个出错的分组 。
信道利用率
停止等待协议的优点是简单,但缺点是信道利用率太低。
信道利用率计算式:
为了提高传输效率,可以采用流水线传输:
发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。由于信道上一直有数据不间断地传送,这种传输方式可获得很高的信道利用率。
5.4.2 连续ARQ协议
ARQ协议,即自动重传请求(Automatic Repeat-reQuest),是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议,拥有错误检测(Error Detection)、正面确认(Positive Acknowledgment)、超时重传(Retransmission after Timeout)和 负面确认及重传(Negative Acknowledgment and Retransmission)等机制。
设置一个发送窗口,实质就是一个数字,如下图的连续将五个分组发送出去而不等待对方确认,当发送方每接收一个确认,发送窗口就向前滑动一个分组的位置。
回退n帧(go-back-n)ARQ
回退n帧ARQ可以看做是发送窗口 > 1 ,接收窗口 = 1的滑动窗口协议,这就是说接收方不必对收到的分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认,这就表示:到这个分组为止的所有分组都已正确收到了。
但网络状况不好的时候会出现,如发送窗口为 10 时,一次发送 10 个数据包,前面两个正确返回了,但第三个丢失了,这时发送方就得重新从第三个包开始,把后面的再传一遍,接收方也必须抛弃前面的 4 - 10 这几个帧,所以网络不佳的情况下可能会比停止等待ARQ还慢。
选择重传(selective repeat)ARQ
回退n帧ARQ在出现错误帧时,发送方要把错误帧之后的所以帧重发一遍,在网络情况不佳的时候只会进一步恶化网络。
选择重传ARQ可以看做是发送窗口 > 1 ,接收窗口 > 1的滑动窗口协议,其会在接收端缓存所有收到的帧,当某个帧出现错误则只需要重传这个错误的帧即可,只有当收到的帧序号都正确了才会往高层应用传递。
选择重传ARQ的缺点是相较于回退n帧ARQ,其在服务端需要更多的缓存。
累积确认:
接收方通常采用累积确认的方式,收到几个分组后将最后一个分组发送确认,表示这个分组之前的所有分组都已确认。
优点:容易实现,即使确认丢失也不必重传。
缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息。
TCP 可靠通信的具体实现
- TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
- TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。
- TCP 两端的四个窗口经常处于动态变化之中。
- TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。
5.5 TCP报文段的首部格式
TCP首部前20个字节是固定的,后面为可选字段,因此TCP首部最小长度20字节。
首部固定字段意义:
- 源端口和目的端口:各占2字节,分别写入源端口和目的端口号,从而通过实现分用
- 序号:占4个字节,表示携带的数据报首个字节的序号,因此总感觉字段也称为“报文段序号”
- 确认号:占4个字节,是期望对方下一个报文段的第一个数据字节序号,若确认号=N,则表明到序号N-1为止的所有数据都已正确收到
- 数据偏移:占4位,表明TCP数据起始处位置,数据偏移单位为32位(4个字节),因此TCP首部最大长度不超过60字节(4*2^4)
- 保留:占6位
- 6个控制位
- 紧急URG:当URG=1,表明紧急指针字段有效,URG字段可使报文段在发送方传输时进行加急插队
- 推送PSH:发送方将PSH置1,接收方收到PSH=1的报文段,会尽快交付到应用程序,也就是在接收方进行加急插队
- 确认ACK:仅当ACK=1时确认号字段才有效,TCP规定在建立连接后所有传送的报文段都必须将ACK置1
- 同步SYN,在建立连接时用来同步序号,SYN = 1 表示这是一个连接请求或连接接受报文
- 复位RST:当 RST = 1 时,表明 TCP 连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。
- 终止FIN:用来释放一个连接。FIN = 1 表明此报文段的发送端的数据已发送完毕,并要求释放运输连接
- 窗口:占2个字节,用来让对方设置发送窗口的依据。窗口字段指明选择允许对方发送的数据量
- 校验和:占2个字节,检验和字段检验的范围包括首部和数据这两部分。在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部
- 紧急指针:占2个字节,只有URG=1紧急指针才有意义,它支持本报文段中紧急数据的字节数
- 选项:长度可变,最长可达40字节,TCP最初只规定了一种选项MSS表示报文段的数据字段的最大长度(数据字段+TCP首部=TCP报文段)
5.6 TCP可靠传输的实现
为方便讨论,这里我们假定数据传输只在一个方向进行(实际一般都是双向进行的)
5.6.1 以字节为单位的滑动窗口
假设A收到B发送的确认报文段,得知B的接收窗口是20,确认号是31,于是A就将发送窗口设为20,然后向B发送31以后的大小不定的报文段,直到发送窗口的字节发送完毕,B收到A发送的报文段,累积一定的字节(假设为10字节)就会发送确认信息并加上确认号41,发送完确认信息软件就能从接收缓存读取接收的报文段,并且接收窗口会往后移动,A收到确认信息同样发送窗口也会往后移动。
A 收到新的确认号,发送窗口向前滑动:
A 的发送窗口内的序号都已用完,但还没有再收到确认,必须停止发送。
发送缓存与接收缓存的作用
发送缓存用来暂时存放:
- 发送应用程序传送给发送方 TCP 准备发送的数据;
- TCP 已发送出但尚未收到确认的数据。
接收缓存用来暂时存放:
- 按序到达的、但尚未被接收应用程序读取的数据;
- 不按序到达的数据。
5.6.2超时重传的选择
重传机制是 TCP 中最重要和最复杂的问题之一。TCP 每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。
加权平均往返时间
TCP 保留了 RTT 的一个加权平均往返时间 RTTS(这又称为平滑的往返时间)。第一次测量到 RTT 样本时,RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本,就按下式重新计算一次 RTTS:
新的 RTTS = (1 − α) x (旧的 RTTS) + α x (新的 RTT 样本)
0< α < 1。若 α 很接近于零,表示 RTT 值更新较慢。若选择 α 接近于 1,表示 RTT 值更新较快。RFC 2988 推荐的 α 值为 1/8,即 0.125。
选择确认SACK
当收到的报文段无差错,只是未按序号,就可以采用确认选择作为一种处理方法:
如图所示前面是连续的字节流,但是出现了两个字节块并未按顺序接收到,这里就使用了指针进行标记边界,L表示左边界,也就是字节块第一个字节,R表示右边界,这里说明是字节块最后一个字节的后一位。通过这两个指针就可以将信息发送给发送方,说明已经接受到了这个字节块。
5.7 TCP的流量控制
流量控制(flow control)就是让发送方的发送速率不要太快,既要让接收方来得及接收,也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在 TCP连接上实现流量控制。
通过滑动窗口机制可以动态调整双方的发送与接收窗口,从而不至于一次性发送大量数据而导致接收方处理不过来。
A与B建立连接,B告诉A它的接收窗口rwnd是400字节
发送方一直等待接收方的确认信息,但是确认报文段可能中通丢失,这样A一直等待B的确认,B一直等待A发送数据,产生相互等待的死锁。为了解决这个问题
TCP 为每一个连接设有一个持续计时器,只要 TCP 连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带 1 字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零,则收到这个报文段的一方就重新设置持续计时器。 若窗口不是零,则死锁的僵局就可以打破了。
5.8 TCP的拥塞控制
5.8.1 拥塞控制的一般原理
在某段时间,若对网络中某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏——产生拥塞(congestion)
出现资源拥塞的条件:
对资源需求的总和 > 可用资源
拥塞控制与流量控制的关系:
- 拥塞控制就是防止过多的数据注入到网络中,使网络中的路由器或链路不至于过载
- 流量控制是指点对点通信量的控制,是端到端的问题
5.8.2 TCP的拥塞控制方法
TCP拥塞控制算法有四种:
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
慢开始和拥塞避免
拥塞控制也叫做基于窗口的拥塞控制,发送方维持一个叫做拥塞窗口 cwnd (congestionwindow)的状态变量。
慢开始算法的原理:增大发送端的拥塞窗口cwnd,可以使分组注入到网络的速率更加合理。使用慢开始算法后,每经过一个传输轮次,拥塞窗口cwnd就加倍。
为了防止拥塞窗口cwnd增长过大引起网络拥塞,需要设置一个慢开始门限ssthresh状态变量,慢开始用法如下:
- 当 cwnd < ssthresh 时,使用慢开始算法。
- 当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
- 当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法。
- 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大,即每经过一个往返时间 RTT 就把发送方的拥塞窗口cwnd 加 1,而不是加倍,使拥塞窗口 cwnd 按线性规律缓慢增长。
乘法减小(multiplicative decrease)
“乘法减小“是指不论在慢开始阶段还是拥塞避免阶段,只要出现一次超时(即出现一 次 网 络 拥 塞 ) , 就 把 慢 开 始 门 限 值ssthresh 设置为当前的拥塞窗口值乘以0.5。当网络频繁出现拥塞时,ssthresh 值就下降得很快,以大大减少注入到网络中的分组数。
加法增大(additive increase)
“加法增大”是指执行拥塞避免算法后,在收到对所有报文段的确认后(即经过一个往返时间),就把拥塞窗口 cwnd增加一个MSS 大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。
快重传和快恢复
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段
快恢复算法
(1) 当发送端收到连续三个重复的确认时,就执行“乘法减小”算法,把慢开始门限 ssthresh减半。但接下去不执行慢开始算法。
(2)由于发送方现在认为网络很可能没有发生拥塞,因此现在不执行慢开始算法,即拥塞窗口cwnd 现在不设置为 1,而是设置为慢开始门限 ssthresh 减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。
发送窗口的上限值
发送方的发送窗口的上限值应当取为接收方窗口rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个,即应按以下公式确定:
发送窗口的上限值 = Min [rwnd, cwnd]
5.9 TCP的运输连接管理
运输连接有三个阶段:
- 连接建立
- 数据传输
- 连接释放
TCP 连接的建立都是采用客户服务器方式。主动发起连接建立的应用进程叫做客户(client)。被动等待连接建立的应用进程叫做服务器(server)。
5.9.1 TCP的连接建立(三次握手)
TCP建立连接的过程叫握手,握手需要客户与服务器之间交换三个TCP报文段。
下面是三次握手的内容(ACK:确认位,SYN:同步位,seq:序号,表示报文段数据的第一个字节,ack:确认号,表示希望收到对方下一个报文段的第一个数据字节序号)
- 客户机A 的 TCP 向 B 发出连接请求报文段,其首部中的同步位 SYN = 1,并选择序号 seq = x,表明传送数据时的第一个数据字节的序号是 x。(此时主机A处于SYN-SENT状态)
- 服务器B的TCP收到报文请求后,如果同意建立连接,就会发送确认报文,报文内容为SYN = 1,使 ACK = 1,确认号ack = x + 1,自己选择的序号 seq = y。(此时主机B处于SYN-RCVD状态)
- A收到B的确认报文后,向B发送确认报文,此时ACK=1,seq=x+1,ack=y+1,同时A的TCP通知上层应用连接已经建立(此时A处于ESTABLISHED状态)
- B收到确认报文同样通知上层应用:TCP建立已经连接(B也处于ESTABLISHED状态)
注意事项:
- 一开始双方都处于CLOSED(关闭)状态,本例中A主动打开连接,B被动打开连接,双方都首先要创建TCB传输控制模块,然后B将处于LISTEN监听状态(使用80端口)
- 前两次握手SYN位都置1,而ACK位三次都置1,前两次都是SYN同步报文段,所以后面的seq序号都只+1,第三次握手如果不携带数据,下一个数据报文段序号仍然为seq=x+1
为什么前两次已经建立连接,仍然需要第三次握手?
假定出现这种情况:A发送了第一个请求连接,请求报文段并未丢失,而是在网络中滞留了一段时间,A因为没收到确认报文,于是重传了一次连接请求,然后与B正常建立了连接,这时B收到了A第一次发送的请求报文因为A又发了一次新的连接请求,于是向A发送确认报文段,同意建立连接。假如没有第三次握手,B发出确认后,连接已经建立。但是A并未请求新的连接,于是会丢弃B的确认报文,而B因为新的连接已经建立,一直等待A发送数据,这样就造成B的许多资源浪费。
5.9.2 TCP的连接释放(四次挥手)
传输结束后,双方可释放连接,选择A和B都处于ESTABLSHED状态(终止位FIN同样不携带数据,但是要消耗一个序号)
下面是四次挥手过程:
- A数据传输完成,发送连接释放报文,将FIN=1,seq=u等待B的确认(此时A处于FIN-EAIT-1状态)
- B收到释放连接报文段后发出确认,ACK=1,seq=v,ack=u+1,TCP服务器进程会通知高层应用,TCP连接处于半关闭状态,只有B还能向A发送数据(此时B进入CLOSE-WAIT状态)
- A收到B的确认,进入FIN-WAIT2状态,等待B的连接释放报文
- 当B没有数据向A发送时,应用进程会通知TCP释放连接,B发送释放连接报文,FIN=1,seq=w,ack=u+1,然后等待A的确认(B进入LAST-ACK最后确认状态)
- A收到B的连接释放报文段后,必须发送确认,将ACK置1,确认号ack=w+1,seq=u+1,然后进入TIME-WAIT状态,但是现在TCP连接还没释放,只有等待2MSL(每个MSL为2分钟)后,A才进入CLOSED状态
- B收到A的确认则立即进入CLOSED状态
MSL叫做最长报文段寿命(Maximum Segment Lifetime),建议时间为2分钟,也可以使用更小的值
为什么A进入TIME-WAIT必须等待 2MSL 的时间?
- 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
- 防止 已失效的连接请求报文段出现在本连接中。A 在发送完最后一个 ACK 报文段后,再经过时间 2MSL,就可以使本连接持续的时间内所产生的所有报文段,都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
第六章 应用层
应用层的具体内容就是规定应用进程在通信时所遵循的协议。
6.1 域名解析系统DNS
6.1.1 域名系统概述
域名系统DNS(Domain Name System)是互联网使用的命名系统,用来把便于入门使用的机器名字转换成IP地址。
因特网采用层次结构的命名树作为主机的名字,并使用分布式的域名系统 DNS,大部分名字都在本地解析解析。名字到 IP 地址的解析是由若干个域名服务器程序完成的。域名服务器程序在专设的结点上运行,运行该程序的机器称为域名服务器。
6.1.2 互联网的域名结构
- 因特网采用了层次树状结构的命名方法。
- 任何一个连接在因特网上的主机或路由器,都有一个唯一的层次结构的名字,即域名。
- 域名的结构由标号序列组成,各标号之间用点
隔开:
… . 三级域名 . 二级域名 . 顶级域名 - 各标号分别代表不同级别的域名
6.1.3 域名服务器
域名服务器有以下四种类型:
- 根域名服务器:最高层次的域名服务器,根域名服务器是最重要的域名服务器。所有的根域名服务器都知道所有的顶级域名服务器的域名和 IP 地址
- 顶级域名服务器:这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。
- 权限域名服务器:负责一个区的域名服务器。
- 本地域名服务器: 当一个主机发出 DNS 查询请求时,这个查询请求报文就发送给本地域名服务器。
域名解析过程
主机向本地域名服务器的查询一般都是采用递归查询。如果主机所询问的本地域名服务器不知道被查询域名的 IP 地址,那么本地域名服务器就以 DNS 客户的身份,向其他根域名服务器继续发出查询请求报文。
域名解析测试(nslookup指令):
6.2 文件传输协议
6.2.1 FTP概述
文件传送协议 FTP (File Transfer Protocol) 是因特网上使用得最广泛的文件传送协议。
FTP协议的四个基本特点:
- 提供交互式的访问,使用户更容易通过操作系统命令与远程系统交互
- 允许客户指定存储文件的类型和格式
- 具备鉴别能力,允许文件有存取权限
- 屏蔽了计算机系统的细节,因而适合在异构的网络中任意计算机之间传送文件
6.2.2 FTP 的基本工作原理
文件传送协议 FTP 只提供文件传送的一些基本的服务,它使用 TCP 可靠的运输服务。FTP 的主要功能是减少或消除在不同操作系统下处理文件的不兼容性。
FTP 使用客户服务器方式。一个 FTP 服务器进程可同时为多个客户进程提供服务。FTP 的服务器进程由两大部分组成:一个主进程,负责接受新的请求;另外有若干个从属进程,负责处理单个请求。
主进程的工作步骤如下
- 打开熟知端口(端口号为 21),使客户进程能够连接上。
- 等待客户进程发出连接请求。
- 启动从属进程来处理客户进程发来的请求。从属进程对客户进程的请求处理完毕后即终止,但从属进程在运行期间根据需要还可能创建其他一些子进程。
- 回到等待状态,继续接受其他客户进程发来的请求。主进程与从属进程的处理是并发地进行。
在文件传输时,FTP的客户和服务器之间要建立两个并行的TCP连接:控制连接和数据连接。控制连接在整个会话期间一直保持打开,FTP 客户发出的传送请求通过控制连接发送给服务器端的控制进程,但控制连接不用来传送文件。实际用于传输文件的是“数据连接”。数据传送进程实际完成文件的传送,在传送完毕后关闭“数据传送连接”并结束运行。
FTP支持两种模式:Standard (PORT方式,主动方式),Passive (PASV,被动方式)。
- Port模式
FTP 客户端首先和服务器的TCP 21端口建立连接,用来发送命令,客户端需要接收数据的时候在这个通道上发送PORT命令。PORT命令包含了客户端用什么端口接收数据。在传送数据的时候,服务器端通过自己的TCP 20端口连接至客户端的指定端口发送数据。FTP server必须和客户端建立一个新的连接用来传送数据。 - Passive模式
建立控制通道和Standard模式类似,但建立连接后发送Pasv命令。服务器收到Pasv命令后,打开一个临时端口(端口号大于1023小于65535)并且通知客户端在这个端口上传送数据的请求,客户端连接FTP服务器此端口,然后FTP服务器将通过这个端口传送数据。
6.3 远程终端协议TELNET
TELNET 是一个简单的远程终端协议, 用户用 TELNET 就可在其所在地通过 TCP 连接注册(即登录)到远地的另一个主机上(使用主机名或 IP 地址)。
为了适应不同计算机系统之间的差异,TELNET定义了网络虚拟终端 NVT :
- 客户软件把用户的击键和命令转换成 NVT格式,并送交服务器。
- 服务器软件把收到的数据和命令,从 NVT格式转换成远地系统所需的格式。
- 向用户返回数据时,服务器把远地系统的格式转换为 NVT 格式,本地客户再从NVT 格式转换到本地系统所需的格式。
此外,telnet也可用于查看某个端口是否可访问。比如我们经常要用的端口就是 8080,那么你可以启动服务器,用telnet 去查看这个端口是否可用。连接失败则会提示,成功则会进入telnet页面(全黑)
6.4 万维网WWW
6.4.1 万维网的概述
万维网 WWW (World Wide Web)是一个大规模的、联机式的信息储藏所。万维网用链接的方法能非常方便地从因特网上的一个站点访问另一个站点,从而主动地按需获取丰富的信息。
万维网是分布式超媒体(hypermedia)系统,它是超文本(hypertext)系统的扩充。
- 超文本: 一个超文本由多个信息源链接成。利用一个链接可使用户找到另一个文档。
- 超媒体:不仅包含文本,还包含其他表示方式的信息,如图形、图像、声音、动画,甚至活动视频图像。
万维网的工作方式
- 万维网以客户服务器方式工作。
- 浏览器就是在用户计算机上的万维网客户程序。万维网文档所驻留的计算机则运行服务器程序,因此这个计算机也称为万维网服务器。
- 客户程序向服务器程序发出请求,服务器程序向客户程序送回客户所要的万维网文档。
- 在一个客户程序主窗口上显示出的万维网文档称为页面(page)。
万维网必须解决的问题
- 怎样标志分布在整个因特网上的万维网文档?
- 使用统一资源定位符 URL (Uniform ResourceLocator)来标志万维网上的各种文档。
- 使每一个文档在整个因特网的范围内具有唯一的标识符 URL。
- 用何协议实现万维网上各种超链的链接?
- 在万维网客户程序与万维网服务器程序之间进行交互所使用的协议,是超文本传送协议HTTP (HyperText Transfer Protocol)。
- HTTP 是一个应用层协议,它使用 TCP 连接进行可靠的传送。
- 怎样使各种万维网文档都能在因特网上的各种计算机上显示出来,同时使用户清楚地知道在什么地方存在着超链?
- 超文本标记语言 HTML (HyperText Markup Language)使得万维网页面的设计者可以很方便地用一个超链从本页面的某处链接到因特网上的任何一个万维网页面,并且能够在自己的计算机屏幕上将这些页面显示出来。
- 怎样使用户能够很方便地找到所需的信息?
- 为了在万维网上方便地查找信息,用户可使用各种的搜索工具(即搜索引擎)。
6.4.2 统一资源定位符 URL
统一资源定位符 URL 是对可以从因特网上得到的资源的位置和访问方法的一种简洁的表示。
URL的格式
由以冒号隔开的两大部分组成,并且在 URL中的字符对大写或小写没有要求。
使用 HTTP 的 URL
使用 HTTP 的 URL 的一般形式:
http://<主机>:<端口>/<路径>
例如清华大学的官网主页URL为:
开头指明了http,然后是主机域名,这里省略了端口号80,最后是路径名,一htm结尾表示是用超文本标记语言HTML写出的文件。
6.4.3 超文本传送协议 HTTP
HTTP操作过程:
- 浏览器分析超链指向页面的 URL。
- 浏览器向 DNS 请求解析 www.tsinghua.edu.cn 的IP 地址。
- 域名系统 DNS 解析出清华大学服务器的 IP 地址。
- 浏览器与服务器建立 TCP 连接
- 浏览器发出取文件命令:GET /chn/yxsz/index.htm。
- 服务器给出响应,把文件 index.htm 发给浏览器。
- TCP 连接释放。
- 浏览器显示“清华大学院系设置”文件 index.htm中的所有文本。
HTTP 的主要特点
- HTTP 是面向事务的客户服务器协议。
- HTTP 1.0 协议是无状态的(stateless)。
- HTTP 协议本身也是无连接的,虽然它使用了面向连接的 TCP 向上提供的服务。
- HTTP/1.1 协议使用持续连接。
持续连接的两种工作方式
- 非流水线方式
- 流水线方式
代理服务器(proxy server)
- 代理服务器(proxy server)又称为万维网高速缓存(Web cache),它代表浏览器发出 HTTP 请求。
- 万维网高速缓存把最近的一些请求和响应暂存在本地磁盘中。
- 当与暂时存放的请求相同的新请求到达时,万维网高速缓存就把暂存的响应发送出去,而不需要按 URL 的地址再去因特网访问该资源。
使用高速缓存可减少访问因特网服务器的时延
HTTP 的报文结构
HTTP 有两类报文:
- 请求报文——从客户向服务器发送请求报文。
- 响应报文——从服务器到客户的回答。
- 开始行:用于区分请求报文和响应报文,
- 方法用于表示实际的操作,URL,版本,CRLF分别代表“回车” 和“换行”,状态码表示返回的状态信息
- 首部行:用于说明浏览器、服务器或报文主体的一些信息
- 实体主体:一般不用这个字段
6.5 电子邮件
电子邮件(e-mail)是因特网上使用得最多的和最受用户欢迎的一种应用。
发送邮件的协议:SMTP
读取邮件的协议:POP3 和 IMAP
通用互联网邮件扩充MIME 在其邮件首部中说明了邮件的数据类型(如文本、声音、图像、视像等),使用 MIME 可在邮件中同时传送多种类型的数据。
6.6 动态主机配置协议DHCP
互联网的计算机协议软件需要配置的项目包括:
- IP地址
- 子网掩码
- 默认路由器的IP地址
- 域名服务器的IP地址
互联网广泛使用的是动态主机配置协议DHCP(Dynamic Host Configuration Protocol),它提供了一种即插即用的机制。
DHCP 使用客户服务器方式。并不是每个网络上都有 DHCP 服务器,这样会使 DHCP 服务器的数量太多。现在是每一个网络至少有一个 DHCP 中继代理,它配置了 DHCP 服务器的 IP 地址信息。
DHCP 协议的工作过程
- DHCP 服务器被动打开 UDP 端口 67,等待客户端发来的报文。
- DHCP 客户从 UDP 端口 68发送 DHCP 发现报文。
- 凡收到 DHCP 发现报文的 DHCP 服务器都发出 DHCP 提供报文,因此 DHCP 客户可能收到多个 DHCP 提供报文。
- DHCP 客户从几个 DHCP 服务器中选择其中的一个,并向所选择的 DHCP 服务器发送 DHCP 请求报文。
- 被选择的 DHCP 服务器发送确认报文DHCPACK,进入已绑定状态,并可开始使用得到的临时 IP 地址了。
- 租用期过了一半(T1 时间到),DHCP 发送请求报文 DHCPREQUEST 要求更新租用期。
- DHCP 服务器若同意,则发回确认报文DHCPACK。DHCP 客户得到了新的租用期,重新设置计时器。
- DHCP 服务器若不同意,则发回否认报文DHCPNACK。这时 DHCP 客户必须立即停止使用原来的 IP 地址,而必须重新申请 IP 地址(回到步骤2),若 DHCP 服 务 器 不 响 应 步 骤 的 请 求 报 文DHCPREQUEST , 则 在 租 用 期 过 了87.5% 时 ,DHCP 客户必须重新发送请求报文DHCPREQUEST(重复步骤6),然后又继续后面的步骤。
- DHCP 客户可随时提前终止服务器所提供的租用期,这时只需向 DHCP 服务器发送释放报文 DHCPRELEASE 即可。
通过ipconfig指令查看DHCP动态配置IP地址:
我们可以通过ipconfig/realse主动将连接释放,然后通过ipconfig/renew再次获取IP地址:
再次查看IP地址的分配:
常见问题总结
-
数据链路层:
- 数据链路层为网络层提供可靠的数据传输;
- 基本数据单位为帧;
- 主要的协议:以太网协议; - 两个重要设备名称:网桥和交换机。常见的交换机有以太网交换机。
A,B中的中继器(Repeater)和集线器(Hub)是物理层的,路由器是网络层的
-
UDP的特点如下:
(1)无链接
(2)UDP使用尽最大努力交付,不保证可靠性
(3)UDP是面向报文的,UDP对应用层交付下来的报文,既不合并,也不拆分,而是保留这些报文的边界。应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文
(4)UDP没有拥塞控制
(5)UDP支持一对一、一对多、多对一和多对多的交互通信
(6)UDP的首部开销小,只有8字节
TCP的特点:
(1)TCP是面向连接的
(2)每条TCP连接只能用于两个断点,一对一
(3)TCP提供可靠交付的服务:连接传输数据、无差错、不丢失、不重复、并且按序到达
(4)TCP提供全双工通信
(5)面向字节流。TCP根据对方给出的窗口和当前网络拥塞的程度来决定一个报文应该包含多少个字节
TCP如何提供可靠性的连接:
(1)数据被分割成TCP认为最合适发送的数据块
(2)重传机制:TCP发出一个段后,启动定时器,如果不能及时收到报文段,则重发一个报文段
(3)当TCP收到一个段后,会发送一个确认
(4)TCP将保持它首部和数据的校验和
(5)TCP对收到的数据进行重新排序,保证数据的有序
(6)TCP会丢弃重复的数据
(7)TCP提供流量控制