NET-05传输层

1. 概述

1.1 传输层两个协议应用场景：

TCP：分段、编号、流量控制、建立会话查看会话命令：netstat -n
UDP：一个数据报就能完成数据通信、不建立会话、用于多播（组播）

• 实例：

进程	协议
QQ传文件	TCP
QQ聊天	UDP
访问网站	TCP（一个数据包传不下来，需要分段 -> TCP）
文件传输协议 FTP	TCP

• 运输协议数据单元
  TCP：TCP报文段（Segment）
  UDP：UDP报文或用户数据报

1.2 传输层与应用层的关系：

书上：端口复用（扩展传输层协议）
传输层协议加个端口号标识对应的应用层协议（就是一个名：指代 TCP+端口号）

应用层协议	对应传输层协议+端口
http	TCP+80
https	TCP+443
ftp	TCP + 21
SMTP	TCP + 25
POP3	TCP + 110
RDP	TCP + 3389
共享文件夹	TCP + 445
SQL	TCP + 1433
DNS	UDP + 53 or TCP + 53

1.3 应用层协议与服务的关系：

用端口来定位（区分）服务类型，用IP地址来定位计算机
：服务（对外提供的服务）运行后在TCP或UDP的某个端口侦听客户端的请求

命令：
netstat -an ：查看自己计算机侦听的端口
telnet 10.7.1.53 21：打开远程计算机打开的端口

安装telnet客户端方法：

1.4 一些应用

使用TCP/IP筛选来实现服务器安全：win10没找到…

Windows防火墙作用：

相当于在网络上隐身了

把所有端口都关了：让外面来的数据报进不来，但自己出去的还能回来（动态打开，类似于“保安”）

防火墙不能防控灰鸽子木马程序：上网不小心中了木马（种在本地）：内鬼！

通过查会话来发现：

2. UDP协议

2.1 报文格式：

没有序号

3. TCP协议

传输控制协议：
TCP就是在传输层上扩展IP协议（在端系统上实现），以解决IP丢包，无序…等问题，实现可靠传输

三大问题：可靠传输、流量控制、拥塞避免
特点：
面向连接：传数据前先相互确认连通（3次握手），并商量好一些参数（如发送序号…）
点到点(点是指：套接字<IP地址+端口号>)
全双工通信
面向字节流（因为 在端系统软件实现？字节：一个字符8位ASCIIA码）

3.1 TCP报文段首部格式：

• 序号seq：数据部分第一个字节的序号

• 确认号ack：期望收到的下一个序号（已收到的最后一个+1）

• 数据偏移：==首部长度（4位二进制：最大15 -> 单位4B）

• 首部标记位：

• URG（urgent）:比如停止指令，跳过发送缓存，优先传给对方通知结束传输（和紧急指针搭配使用）

• ACK：确认位

• SYN：同步位（建立会话请求）

SYN攻击：伪造一些不存在的请求和服务器建立会话，服务器找不到源端口，占用资源，处理不过来

• PUSH：跳过接收缓存，直接交付给客户端应用程序
• RST：重置，出现严重错误（掉线），必须释放连接，再重新建立建立
• 窗口：通知对方自己当前的接收窗口，以便对方调整发送窗口大小
• 校验和：校验首部和数据（IP只校验首部），和UDP一样+12字节伪首部，但第4个字段（协议）17改为6
• 紧急指针：指明需要紧急处理部分的末尾

打开网页时图片一点点加载出来的过程，就是TCP传输的过程

3.2 如何实现可靠传输：

• 原理：

a. 无差错(理想情况下：接收方永远能及时接收)情况：停止等待协议
b. 超时重传：连续ARQ
b1.确认丢失：确认帧丢失，发送方收不到确认帧，超时重传，接收方重复收到该帧后：丢弃该帧 -> 重传确认帧
b2.确认迟到：确认帧到之前发送方超时重传，接收方重复收到该帧 -> 丢弃，重传确认帧，这时路上有两个确认帧（之前还没到的和刚发的），发送方对迟到的那个确认帧采取的方案是丢弃，什么也不做

总结：不管是数据还是确认，只有收到重复的就丢弃，如果是数据就重传确认，如果是确认丢弃后什么也不干
- 信道利用率：

如果使用停止等待协议：

• 如何提高信道利用率：
  提高T_D （RTT、T_A（较小）比较固定）
  -》 实现方法：一直发数据报，不等待确认，即流水线传输（使用连续ARQ ->滑动窗口）
  -》通过累积确认，再次提高信道利用率：

3.3 如何实现流量控制：

• 以字节为单位的滑动窗口：

• 超时重传时间的选择：略大于RTTs(比RTT短，确认帧还没回来，不能确定是不是丢了)
  α推荐1/8，值越大说明修正的越及时（比如取1，完全由新RTT替换）

3.4 如何避免网络 拥塞：

针对网络中所有的主机：大家共同维护网络的通畅！

1. 拥塞窗口cwnd（congestion window）
2. 接收窗口rwnd（receive window）

• 发送窗口上限值 = Min{rwnd , cwnd}；

3.4.1 慢开始算法（乘法增大）

先发一个包（MSS），试探一下看通不通，此后每收到一个确认cwnd+1，即每轮加倍

3.4.2 拥塞避免算法（加法增大）

当cwnd增大到慢开始门限(ssthresh)后（即这轮结束后cwnd理论上>ssthresh），从ssthresh开始(不继续指数增长，见图中★) 每轮cwnd+1

3.4.3 快重传算法（90年新增：）

假设原来是每过5个数据报发一次确认，如果收到第4个数据报时已经知道3号丢了，如果按原来的方式等到第5个，还有重传4和5，白传
-》 改进：对3号连续发送3个确认，收到后直接重传3以后的

总结：接收端发现丢包，立刻三连发，通知发送端，发送端收到三连就重传

3.4.4 快恢复算法（90年新增：）

快重传算法中：发送端收到三连说明网可能没堵，毕竟还收到三连确认，故cwnd不用从1开始，而是从ssthresh开始线性增长

3.5 TCP传输的连接管理：

传输连接三阶段：连接建立，数据传输、连接释放

3.5.1 连接建立：三次握手

• 3次才能完全保证连接建立：
  如果2次握手，考虑情况：A连续发送两次请求建立，因为第一次比较慢（超时了），第二次很快就到了，B确认第二个，连接建立，开始传数据
  ！！别忘了路上现在还有个请求报文（第一个）正在龟速赶来（还是能到），当这个请求到B以后，B给A发相应的确认，A收到这个确认后认为是重复确认 -> 丢弃（因为已经开始正常传输数据了，重复确认丢弃）

三次握手时两端的状态：

命令：netstat -n查询

3.5.2 连接释放：四次挥手