mirror of
https://github.com/Didnelpsun/CS408.git
synced 2026-02-12 15:16:04 +08:00
更新
This commit is contained in:
@@ -41,12 +41,12 @@ HTTPS|443
|
||||
|
||||
## UDP协议
|
||||
|
||||
用户数据报协议只在$IP$数据报服务之上添加了两个功能,即只有复用分用与差错检测功能。
|
||||
用户数据报协议只在$IP$数据报服务之上添加了两个功能,即只有复用分用(接收方的传输层剥去报文首部后,能把这些数据正确交付到目的进程。通过目的端口实现)与差错检测功能。
|
||||
|
||||
### 主要特点
|
||||
|
||||
1. 无连接,减少开销和发送数据之前的时延。
|
||||
2. 使用最大努力交付,而非保证可靠交付。
|
||||
2. 使用最大努力交付,而非保证可靠交付。所以不会对报文编号。
|
||||
3. 面向报文(不对报文拆分,应用层给多长报文,$UDP$就会照样一次发送一个完整报文),适合一次性传输少量数据的网络应用。
|
||||
4. 无拥塞控制,适合很多实时应用,实时应用延迟要求高,需要立即响应。
|
||||
5. 支持一对一、一对多、多对一、多对多的交互通信。
|
||||
@@ -61,7 +61,7 @@ HTTPS|443
|
||||
+ 源端口号:需要对方回应时选用,如果不需要回应,可以不填,即是全$0$的。
|
||||
+ 目的端口号:是必填的。分用时,如果找不到对应的目的端口号就丢弃该报文,并向发送方发送$ICMP$端口不可达差错报告报文。
|
||||
+ $UDP$长度:整个$UDP$用户数据报的长度,首部加上数据部分。最小值为$8$。以字节为单位。
|
||||
+ $UDP$检验和:检测整个$UDP$数据报是否有错,错就丢弃。若不想校验则是全$0$。若计算结果为全$0$则置为全$1$。
|
||||
+ $UDP$检验和:检测整个$UDP$数据报是否有错(首部+数据,而$IP$只检测首部),错就丢弃。若不想校验则是全$0$。若计算结果为全$0$则置为全$1$。
|
||||
|
||||
### UDP协议校验和
|
||||
|
||||
@@ -75,15 +75,19 @@ HTTPS|443
|
||||
|
||||
发送端:
|
||||
|
||||
如果不使用校验和字段,则字段全部填充$0$。
|
||||
|
||||
1. 填上$12B$的伪首部。
|
||||
2. 全$0$填充检验和字段。
|
||||
3. $UDP$数据报要看成许多$16$位的字符串连接一起,全$0$填充数据部分末尾,使数据报成为偶数个字节。
|
||||
4. 伪首部+首部+数据部分采用二进制反码求和。
|
||||
5. 把和求反码填入校验和字段。
|
||||
5. 二进制反码运算求和再取反填入校验和字段。
|
||||
6. 去掉伪首部进行发送。
|
||||
|
||||
接收端:
|
||||
|
||||
如果校验和字段计算结果恰好为$0$,则表示错误,字段全部填充$1$。
|
||||
|
||||
1. 填上伪首部,若不是偶数个字节还要在末尾加$0$。
|
||||
2. 伪首部+首部+数据部分采用二进制反码求和。
|
||||
3. 如果结果全为$1$则无差错,否则出错,丢弃或交给应用层并附上出错的警告。
|
||||
@@ -111,7 +115,7 @@ $TCP$传输的数据单位称为报文段。可以用来传输数据,也可以
|
||||
+ 源端口和目的端口:各$2B$。
|
||||
+ 序号:在一个$TCP$连接中传送的字节流中的每一个字节都按顺序编号,本字段表示本报文段所发送数据的第一个字节的序号。范围为$0\sim2^{32}-1$。
|
||||
+ 确认号:期望收到对方下一个报文段的第一个数据字节的序号。若确认号为$N$,则证明到序号$N-1$为止的所有数据都已正确收到。
|
||||
+ 数据偏移(首部长度):$TCP$报文段的数据起始处距离$TCP$报文段的起始处有多远,即$TCP$报头的长度。以$4B$位单位,即$1$个数值是$4B$。,最大值为$15$,达到$TCP$首部的最大值$60B$。
|
||||
+ 数据偏移(首部长度):$TCP$报文段的数据起始处距离$TCP$报文段的起始处有多远,即$TCP$报头的长度。以$4B$位单位,即$1$个数值是$4B$,最大值为$15$,达到$TCP$首部的最大值$60B$。
|
||||
+ 保留:目前为$0$。
|
||||
|
||||
还有六个控制位,除了$PSH$和$RST$位都较重要:
|
||||
@@ -177,7 +181,7 @@ TCP建立连接采用客户服务器方式。但是实际上任何一台计算
|
||||
![TCP释放连接][TCPreleaselink]
|
||||
|
||||
1. 最开始客户端与服务端都是已建立连接状态。
|
||||
2. 客户端发送连接释放报文段,停止发送数据,主动关闭$TCP$连接,进入终止等待状态。
|
||||
2. 客户端发送连接释放报文段,停止发送数据,主动关闭$TCP$连接,进入终止等待$1$状态。
|
||||
3. 服务端会回送一个确认报文段,此时服务器端进入关闭等待状态,客户到服务器这个方向的连接就释放了——半关闭的状态,不允许客户端再发送数据给服务器。
|
||||
4. 客户端接受报文段后进入终止等待$2$状态。
|
||||
5. 服务器发完数据,如果没有要向服务器发送的数据,就发出释放连接报文段,主动关闭$TCP$连接,进入最后确认阶段。
|
||||
@@ -189,14 +193,14 @@ TCP建立连接采用客户服务器方式。但是实际上任何一台计算
|
||||
+ $FIN=1$:主机$A$要释放连接。
|
||||
+ $seq=u$(随机):后面可以有数据也可以没有数据。
|
||||
2. 第二部分:
|
||||
+ $ACK=1$:连接建立了,之后的$ACK$必须都置为1。
|
||||
+ $ACK=1$:连接建立了,之后的$ACK$必须都置为$1$。
|
||||
+ $seq=v$(随机):$v=u+$第一部分数据长度$+1$,如果第一部分的确认报文没有数据就是$v=u+1$。
|
||||
+ $ack=u+1$:之前发送方$A$发送的是第$u$位数据,所以主机$B$要的是$u+1$位数据(尽管此时$A$已经决定释放连接了)。
|
||||
3. 第三部分:
|
||||
+ $FIN=1$:主机$B$要释放连接。
|
||||
+ $ACK=1$:连接建立了,之后的ACK必须都置为1。
|
||||
+ $ACK=1$:连接建立了,之后的$ACK$必须都置为$1$。
|
||||
+ $seq=w$(随机):$w=v+$第二部分数据长度$+1$,如果第二部分的确认报文没有数据就是$w=v+1$。
|
||||
+ $ack=u+1$:之前发送方$A$说发送的是第u位数据,所以主机$B$要的是$u+1$位数据(因为A直接不发数据了,所以第二段第三段的$ack$都是$u+1$)。
|
||||
+ $ack=u+1$:之前发送方$A$说发送的是第$u$位数据,所以主机$B$要的是$u+1$位数据(因为A直接不发数据了,所以第二段第三段的$ack$都是$u+1$)。
|
||||
4. 第四部分:
|
||||
+ $ACK=1$:连接建立了,之后的$ACK$必须都置为$1$。
|
||||
+ $seq=u+1$:之前发的数据时第$u$位数据,$B$也要第$u+1$位数据,所以我发第$u+1$位数据。
|
||||
@@ -204,7 +208,7 @@ TCP建立连接采用客户服务器方式。但是实际上任何一台计算
|
||||
|
||||
为什么要等待$2MSL$时间?
|
||||
|
||||
1. 保证$A$发送的最后一个$ACK$报文段能发送到$B$,否则$B$服务器会不断接收$A$重传的信息从而无法正常关闭。
|
||||
1. 保证$A$发送的最后一个$ACK$报文段能发送到$B$,否则$B$服务器会接收不到$A$确认的信息,而$A$已经关闭无法重发确认报文段,从而$B$无法正常关闭。
|
||||
2. 防止已失效的连接请求报文段传输到下一次的连接请求,干扰下一次的连接服务。
|
||||
|
||||
### TCP协议可靠传输
|
||||
@@ -223,6 +227,8 @@ $TCP$报文传输时每个字节都会编上序号,一个字节占用一个序
|
||||
|
||||
序号建立在传送的字节流上,而不是报文段。
|
||||
|
||||
虽然$TCP$面向字节,但是不是每个字节都要发回确认,而是在发送一个报文段后才发回一个确认,确认号为报文段第一个字节的序号,所以$TCP$是对报文段的确认机制。
|
||||
|
||||
#### 确认
|
||||
|
||||
确认号是期望收到的下一个报文段数据的第一个字节的序号。
|
||||
@@ -258,7 +264,7 @@ $A$向$B$发送数据,连接建立时,$B$告诉$A$:$B$的$rwnd=400B$,设
|
||||
|
||||
![TCP流量控制][TCPcurrent]
|
||||
|
||||
$B$只有处理完接收窗口中的数据才能继续接收A的数据,发送$A$一个$rwnd$不为$0$的报文。
|
||||
$B$只有处理完接收窗口中的数据才能继续接收$A$的数据,发送$A$一个$rwnd$不为$0$的报文。
|
||||
|
||||
而如果这个告诉$A$接收窗口$rwnd$不为$0$的报文丢失了,$A$就一直会等待发送,$B$就会一直等待接收,从而产生死锁般的情况。
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@
|
||||
2. 每个主机既提供服务也可以提供服务。
|
||||
3. 任意端系统或结点之间可以直接通信。
|
||||
4. 结点间歇接入网络。
|
||||
5. 结点可能改变IP地址。
|
||||
5. 结点可能改变$IP$地址。
|
||||
6. 扩展性好。
|
||||
7. 网络健壮性强。
|
||||
8. 占用较多内存,影响速度。
|
||||
@@ -52,7 +52,7 @@
|
||||
|
||||
### 域名
|
||||
|
||||
域名从右到左级别降低,最右边的是顶级域名,如<www.baidu.com>,$com$就是顶级域名,$baidu$就是二级域名,$www$就是三级域名。其实$com$后面应该有一个点,这个点就是根。
|
||||
域名从右到左级别降低,最右边的是顶级域名,如$www.baidu.com$,$com$就是顶级域名,$baidu$就是二级域名,$www$就是三级域名。其实$com$后面应该有一个点,这个点就是根。
|
||||
|
||||
+ 标号中的英文不区分大小写。
|
||||
+ 标号中除连字符-外不能使用其他的标点符号。
|
||||
@@ -119,6 +119,8 @@
|
||||
|
||||
默认数据传输端口$20$,控制端口$21$。这些端口都是服务器上的,客户端的端口由程序自己分配。
|
||||
|
||||
可以指明文件类型与格式,并可以给予存取权限。
|
||||
|
||||
+ 提供不同种类主机系统之间的文件传输能力。
|
||||
+ $FTP$基于$C/S$模型。用户通过一个客户机程序连接至远程计算机上运行的服务器程序。依照$FTP$协议提供服务,进行文件传输的计算机就是$FTP$服务器,连接$FTP$服务器,遵循$FTP$协议与服务器传送文件的电脑就是$FTP$服务端。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user