计算机网络——传输层

1 端口号

1.1 端口号范围划分

（1）1-1023：知名端口号，
（2）1024-65535：操作系统动态分配的端口号

1.2 查看知名端口号

cat /etc/services

1.3 常见知名端口号

每个服务都有端口号
ssh服务器, 使用22端口
ftp服务器, 使用21端口
telnet服务器, 使用23端口
http服务器, 使用80端口
https服务器, 使用443

1.4 pidof

pidof 进程名：查看指定进程id

1.5 netstat

查看网络状态
-n：可以显示成数字的内容都显示成数字，否则会按照主机名的形式显示
-l：listen监听状态的套接字
-t：tcp
-u：udp
-p：显示建立相关链接的程序名
-a：显示所有选项，默认不显示listen状态

2 传输层

主要协议：tcp和udp

2.1 udp

2.1.1 协议端格式

2.1.2 封装和解包

封装：添加上定长报头
解包：将报头和有效载荷做分离，读取定长报头，剩下的就是有效载荷
16位目的端口号：确定交付给对端主机应用层的哪一个进程

2.1.3 分用

如何向上交付：
解决两个问题
（1）报头和有效载荷分离
（2）根据目的端口号交付有效载荷给上层应用
内核中udp报头是采用结构体位段来表示的

2.1.4 特点

（1）无连接
（2）不可靠
（3）面向数据报：不能灵活地控制读写数据的次数和数量——UDP对于收到的报文，既不会拆分，也不会合并，而是只能原样传输，在主机看来，报文和报文之间是独立的——>没有粘包问题

2.1.5 UDP的缓冲区

UDP没有真正意义上的发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃
UDP的socket既能读, 也能写, 这个概念叫做全双工(收发同时，recvfrom和sendto可以同时被调用)

2.1.6 基于UDP的应用层协议

NFS: 网络文件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议

2.2 TCP

2.2.1 协议端格式

（1）源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去
（2）4位首部长度（报头长度）（4bit位，取值范围0000~1111）（基本单位：4字节）：例如首部长度是10，报文长度=10*4=40字节
TCP最大长度是15*4=60字节
TCP标准长度是固定值20个字节，可计算出首部长度=5=0101
（3）16位窗口大小：自己的接收缓冲区剩余的空间大小，即自己的接受能力，对端以此动态调整发送数据的多少、快慢，避免缓冲区满导致来不及接收，丢包，通过该字段达到流量控制功能；窗口大小越大，网络的吞吐率越高
（4）6个标记位：每个标志位占1bit，0/1，不同标志位代表不同种类的tcp报文
ACK：确认报文的标志位，确认序号+ACK:1，表明是对某个报文做确认
PSH：push，告知对端尽快将接收缓冲区中的数据向上交付
RST：reset，重置异常连接，表明第三次握手没有成功，连接建立失败
SYN：同步标记位，表明是建立连接的请求报文
FIN：断开连接的报文
URG：16位紧急指针是否有效，携带紧急数据的报文可以被优先处理 （带外数据）
（5）16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也
包含TCP数据部分.
（6）16位紧急指针: 标识哪部分数据是紧急数据，tcp的紧急指针只能传输一个字节

2.2.2 封装和解包

将报头和有效载荷的边界确定，就可以实现这两个过程
报头长度为20字节，剩下的内容就是有效载荷

2.2.3 分用

解包之后，再通过16位目的端口号就可以进行向上交付

2.2.4 TCP的缓冲区

TCP自带发送和接收缓冲区
应用层中的系统调用，调用write、send，本质是把数据拷贝到TCP的发送缓冲区；调用read、recv，本质是从TCP的接收缓冲区中取数据，而不是从网络中读数据
缓冲区存在的优点：
（1）提高应用层效率
（2）使应用层和TCO解耦，因为只有TCP可以知道网路甚至对端的状态明细，TCP可以处理收发报文的各种细节问题，应用层无法处理

2.2.5 特点

（1）可靠性
（2）面向连接
（3）面向字节流：只关心多少个字节

2.2.6 可靠性:

校验和

发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分；判断数据有没有错误

序列号(按序到达)：

支持确认应答，按序到达，去重
TCP保证可靠性的核心机制：基于序号的确认应答机制

确认序号=收到的历史报文序号+1，解决了报文接收乱序的问题
为什么将序号和确认序号拆分两部分：因为TCP协议也是全双工的，收发可以同时进行，所以用序号表示自己发出的数据的序号，确认序号表示收到了对端的数据
序号的编排：可以将缓冲区看成字节流式的数组，以字节为单位，那么每一个字节就有了单位（下标），报文序号和它有关，同时丢包重传（1.报文丢失 2.应答丢失）的报文序号和之前是一样的，所以若是应答丢失的情况可以进行去重操作

确认应答：

确认应答：只要一条消息有应答，说明这条消息被对方收到了；但存在问题是最新的一条消息肯定是没有应答的，从而不能确认是否被对方收到——>TCP也不是100%可靠
一端发消息，另一端一直发送确认，就可以保证100%可靠（对历史数据的可靠性）——>收到确认说明数据成功发送到对端，未收到确认就认为数据丢了
确认序号：表示序号之前的报文都已经收到
举例：主机A分7次发送了数据1-7000，正常情况ACK也应该是7次，序号分别是1001，2001，3001，4001，5001，6001，7001；
若ACK丢失，比如4001，5001丢失，但是主机A正常收到了7001，那就认为7001之前的数据全都正常收到；
若数据丢失，比如2001-3000丢失，那么主机B发送确认报文就只能发送1001，2001，之后的5个确认报文也只能发送2001

超时重发

超时重传
在一个特定时间间隔内没有收到应答，就会重发
超时时间
最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”。但是这个时间的长短, 随着网络环境的不同, 是有差异的。如果超时时间设的太长, 会影响整体的重传效率；如果超时时间设的太短, 有可能会频繁发送重复的包。
TCP动态计算最大超时时间
以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍；
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传；
如果仍然得不到应答, 等待 4500ms 进行重传. 依次类推, 以指数形式递增.
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

连接管理：三次握手，四次挥手

三次握手：connect函数
底层TCP协议自动完成
SYN
SYN+ACK：捎带应答
ACK
结束之后建立连接成功（不是百分百，因为最后一个ack没有应答，不能确定收到）
为什么是三次握手
两台主机创建连接之后需要维护连接（先描述再组织）
（1）确认双方主机状态正常，比如os功能正常，IO正常，网络正常
（2）三次是能验证双方都有收发能力的最小次数
（3）一次或两次握手就确定连接容易被海量SYN消耗完服务器资源（SYN洪水攻击）（因为每一个连接都需要数据结构等资源去维护）
四次挥手：双方达成连接关闭的一致认识
A->B：FIN
B->A：ACK
B->A：FIN
A->B：ACK
为什么是四次挥手
强调功能性，四次协商断开连接的最小次数
为什么不是三次：第一次应答被动方此时有可能还有相应的数据报文需要发送，因此需要先发送ACK报文，告知主动方“我知道你想断开连接的请求了”。这样主动方便不会因为没有收到应答而继续发送断开连接的请求

主动断开连接的一方，要进入TIME_WAIT状态，此时连接并没有被释放，还需要维持一段时间，因为最后一次ACK有可能丢失
TIME_WAIT
多长时间？
2MSL(MSL:报文的最大生存时间)
（1）尽量保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失
（2）尽量保证最后一个ACK被对方收到
日常练习出现的bind error和此有关，bind error就是由于服务端的TCP连接没有完全断开之前不允许重新接听引起的

流量控制：

根据接收端的处理能力，控制发送端数据的发送速度，避免丢包
通过报文中的窗口大小得知接收缓冲区的余量
接收端窗口大小=0时发送端不再发送，等到接收端缓冲区有空间时向发送端发送窗口更新通知，若超过重发时间发送端未收到，则发送端发送窗口探测报文

拥塞控制；慢启动

拥塞控制
和网络问题相关，大量丢包认为是网络拥塞，衡量网络拥堵情况的指标
是TCP发现网络拥塞之后尝试去恢复网络状况的一种策略，是TCP既想尽快把数据传输给对方，又要避免给网络造成太大压力的折中方案（宏观认识，这是全体主机都要遵守的规则，网络中有多台使用tcp协议的主机同时监测到网络拥塞）
滑动窗口=min(拥塞窗口，对方的窗口大小)

每次慢开始拥塞窗口cwnd=1，之后是2ⁿ增长，直到等于阈值（即将大于阈值时直接取等于ssthresh），变成线性增长，遇到超时重发则cwnd再次置1
ssthresh（慢启动的阈值）的初始值=窗口最大值，之后超时重发则阈值=上次的1/2

2.2.7 提高性能:

滑动窗口

滑动窗口
窗口大小：无需等待确认应答（短期内）而可以继续发送数据的最大值
滑动窗口：发送缓冲区中存储可以发送或已经发送但未收到确认（短期内不需要）的报文的区域，和对端接受能力有关
对端来不及接收数据会导致滑动窗口变小（左侧右移）
对端从缓冲区拿出了一批数据（对端的窗口大小增大），会导致滑动窗口变大（右侧右移）

快速重传

接收端连续发送三次相同的ACK应答，就会引发快速重传，使发送端重新发送未得到确认的数据

延迟应答

接收数据的主机稍等一些时间再返回ACK应答，使返回的窗口大小变大，提高效率
延迟应答的限制
（1）数量限制: 每隔N个包就应答一次;
（2）时间限制: 超过最大延迟时间就应答一次;
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

捎带应答

捎带应答
确认应答的同时携带有效数据，比如第二次握手

2.2.8 其他特点及策略:

定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等

2.2.9 面向字节流

粘包问题

是面向字节流的特点引发的问题，流式传输只考虑多少个字节，只能看到一连串的字节数据，而不看单个数据包的格式，因此可能接收数据时会读到大于一个或小于一个的不完整应用层数据包
应对措施：明确两个包之间的边界（应用层协议应该做的）
（1）定长字段：对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
（2）自描述字段：对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
（3）特殊字符：对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可)。

比如http协议，就设置了特殊字符\n和自描述字段content-length

2.2.10 基于TCP应用层协议

HTTP
HTTPS
SSH
Telnet
FTP
SMTP
自己写TCP程序时自定义的应用层协议

2.2.11 TCP异常情况

进程终止/机器重启：释放文件描述符，仍然可以发送FIN，和正常关闭没有什么区别，底层自动进行四次挥手
机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放

2.3 其他知识点

端口号如何找到目标进程：
根据目的端口号做哈希，找到目标进程的pcb，从而找到对应的网络文件，包括缓冲区，然后将数据拷贝进去

解决bind error

//在创建完socket之后调用setsockopt
int opt = 1;
setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));
//listenfd：创建套接字返回的描述符
//SOL_SOCKET：指在套接字层

listen accept

accpet之前已经建立好连接，accept是获取

listen的第二个参数backlog：全连接队列的长度
backlog+1=在tcp层建立正常连接的个数（处于ESTABLISHED状态但未被accpet的请求）
=1：只允许两个连接连接成功，多余的是SYN_RECV状态，且只显示最新连接的一个

半连接队列的长度是算法形成的，不同系统通常不同
为什么要维护全连接队列？(为什么这个队列必须存在？)为什么这个队列不能太长？
类比餐厅门外的等候区
没有队列的话可能导致内部资源不能被充分利用（内部有空位但是没有客人及时补位）
长度越长维护成本越高，不如节省资源给服务去使用——>全连接队列是一个短队列