
应用层常见协议概览

基于TCP的协议
基于UDP的协议
RTP(实时传输协议)
DNS(域名管理系统)
用于解决域名和IP地址的映射问题

为什么域名解析用UDP协议
DNS的工作原理
查询方式
递归查询:主机向本地域名服务器的查询一般都是采用递归查询
迭代查询:本地域名服务器向根域名服务器的查询
工作流程
原因:业务错综复杂,很难有一个通用的协议来满足所有业务需求
怎么自定义
结合需求,分析清楚响应要传递哪些信息
明确传递的信息以什么样的格式来组织
典型的组织数据的格式
按照文本方式组织
二进制的表示数据的方式
UDP的特点
UDP报文
UDP报头

源端口
目的端口
UDP长度
UDP校验和
验证传输的数据是否正确
常见算法
CRC
MD5
特点
基于这些特点,更多的用处
SHA1
8个字节,总共有4个部分,每个部分两个字节
UDP载荷(payload)
TCP的特点
有连接
可靠传输
TCP最核心的部分
保证整体TCP的可靠性
面向字节流
全双工
TCP报文
TCP报头

源端口号(16位)
目的端口号(16位)
序列号(32位)
确认应答号(32位)
首部长度(4位)
保留(6位)
控制位
URG
ACK
PSH
RST
SYN
FIN
窗口大小(12位)
选项(长度可变)
数据
TCP载荷
TCP内部的工作机制
确认应答
实现可靠传输最核心的机制
应答报文
解决网络先发后至问题
超时重传
丢包
超时重传
如果出现传输的数据重复的情况怎么办?
小结:去重和重新排序机制
连接管理
建立连接:三次握手

三次握手的意义
1、让通信双方各自建立对对方的“认同”(记录对方的信息)
2、验证通信双方的发送能力和接受能力是否正常
3、在握手的过程中,双方协商一些重要的参数(主要是前两个)
为什么不是四次握手?中间两次交互不合并可以吗?
为什么不是两次握手?
断开连接:四次挥手

为什么要四次挥手?
中间的两次交互为什么不能像三次挥手那样合并在一起呢?
如果第二次挥手时服务器的ACK没有到达客户端,会怎样?
为什么这里的TIME_WAIT要保持当前的TCP连接状态,不能立即释放呢?
最后一个ACK发出,还没有到达,可能会存在丢包情况
而四次挥手也存在超时重传,站在服务器的角度,无论是ACK丢包还是自己发出的FIN丢包,都视为是FIN丢包,会进行FIN重传。如果立即释放,那将无法对重传的FIN进行ACK响应
TIME_WAIT具体保持多少时间释放连接呢?
约定一个时间,叫做2MSL

发送量控制
滑动窗口
为什么引入
本质就是降低了确认应答,等待ACK消耗的时间

批量发送了一批数据之后,就开始等待ACK,那什么时候继续往下发送呢?等待什么时候结束呢?
如果出现丢包怎么办
ACK丢了

数据丢了

快速重传:只重传丢失了的数据

流量控制
一种干预发送的窗口大小的机制
滑动窗口越大,传输效率越高。但是滑动窗口不能无限大
如何衡量接收方的处理能力
看接收方 接收缓冲区的剩余大小
每次主机A向主机B发送数据,B就计算一下剩余空间,然后将这个值通过ACK返回给A。A就根据这个值决定接下来的发送速率(窗口大小)
窗口探测报文不携带任何具体的业务数据,只是为了触发ACK查询窗口大小

窗口大小是随着传输过程,动态变化的
窗口大小只有在报文是ACK时才会生效。并且窗口大小不只是64kb,在选项中有个扩展因子可以让窗口更大

拥塞控制
流量控制和拥塞控制共同决定发送方的窗口是多大(取决于二者较小的一个)
本质上,是通过实验的方式来逐渐找到一个合适的窗口大小(合适的发送速率)

拥塞窗口不是固定数值,而是一直动态变化的,随着时间推移,逐渐达到一个动态平衡的状态。这样既能解决问题,同时也能随着网络的动态变化而动态变化
延时应答

捎带应答

面向字节流
可能出现“粘包现象”
在应用层约定好应用层协议即可,尤其是明确应用层数据报和应用层数据报之间的边界就好了
异常情况
进程崩溃
主机关机
主机掉电/网线断开
接收方掉电
发送方掉电
有保活机制:通过心跳包来确认双方是否处在正常的通信状态
是否面向连接
是否可靠传输
是否有状态
传输效率
传输形式
首部开销
是否提供广播/多播服务

IP(网际协议)
ARP(地址解析协议)
主要作用: 实现从IP地址转换为MAC地址。在每个主机或者路由器中都建有一个ARP缓存表,表中有IP地址及IP地址对应的MAC地址
ARP地址协议
ARP数据传输

ARP的工作流程
ICMP(互联网控制协议)
NAT(网络地址转换协议)
OSPF(开放式最短路径优先)
RIP(路由信息协议)
BGP(边际网关协议)
