传输层的功能：
传输层为相互通信的应用程序提供了逻辑通信（端口到端口）
TCP/UDP 应用场景
TCP 需要将传输的文件分段传输 建立会话 可靠传输 流量控制
UDP 一个数据包完成数据通信 不建立会话 不可靠传输 不需要流量控制
对应的应用层协议和端口：
TCP：
RDP 3389 | FTP 21 | TELNET 23 | SMTP 25 | POP3 110 | HTTP 80 | HTTPS 443 | SQL 1433
UDP：
DNS 53 | TFTP 69 | SNMP 161 | RIP 520
传输层协议号 TCP 6 | UDP 17
端口
16位端口号标识（0~65535）
三类端口：熟知端口(0~1023) | 登记端口号(1024~49151) | 客户端口号(49152~65535)
UDP
主要特点：无连接、最大努力交付、面向报文、任意对任意通信、首部开销小(8字节)
伪首部(网络层首部)：源IP地址(4) + 目的IP地址(4) + XX(1) + 传输层协议号(1) + 传输层首部长度(2)
首部(8)：源端口(2) + 目的端口(2) + 长度(2) + 检验和(2)
检验和计算：先将检验和置为0，然后将伪首部+首部按两字节一组分为n组，对其反码求和，然后再求反码得到检验和
TCP
主要特点：面向连接、可靠交付、可靠交付、只能一对一通信、全双工通信
三个重要知识点：可靠传输、流量控制、避免网络拥塞
TCP连接的端点叫做 socket 套接字，即 IP地址：端口
首部(20)：源端口(2) + 目标端口(2) + 序号(4) + 确认号(4) + [数据偏移(4bit) + 保留(6bit) + URG(1bit) + ACK(1bit) + PSH(1bit) + RST(1bit) + SYN(1bit) + FIN(1bit)](2) + 窗口(2) + 检验和(2) + 紧急指针(2) + (选项(SAC选择性ACK) + 填充)
可靠传输
以字节为单位分块传输
数据校验（检验和）
停止等待机制（每次发送一个数据包都会启动定时器等待确认包）
确认和重传机制（累积确认、选择性确认）
滑动窗口机制（流量控制）
流量控制
TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。
发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值(可增大或减小)。
防止死锁：TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
避免网络拥塞
出现资源拥塞的条件：对资源需求的总和 > 可用资源（带宽不够）
慢开始算法：按照指数的增长速度来慢慢加大cwnd(拥塞窗口)的大小
拥塞避免算法：让cwnd的大小线性增长，一个轮次只增加1
（不论是在慢开始阶段还是拥塞避免阶段，如果出现网络拥塞，ssthresh的大小变为拥塞发生时cwnd值的一半，然后cwnd变为1，在开始慢开始算法）
快重传：当接收方收到一个失序的数据，可以立刻向发送方发送重复确认信息，而不会等到发送下一个确认时捎带发送，发送方只要接收三个连续的重复确认，就会立刻重复发送刚才没有收到确认的数据
快恢复：与快重传配合使用，当发送方接收到连续三个重复确认请求，为了避免网络拥塞，就会把ssthresh的值减少为当然拥塞窗口的一半，但是发送方认为当前网络并没有发生拥塞，因为还可以接收到三个确认请求，所以不会去执行慢开始算法，而是执行拥塞避免算法
传输连接管理
连接建立
第一次握手：SYN = 1，ACK = 0，seq = x
第二次握手：SYN = 1，ACK = 1，seq = y，ack = x + 1
第三次握手：ACK = 1，seq = x + 1, ack = y + 1
客户端状态 CLOSED → SYN_SENT → ESTABLISHED
服务端状态 LISTEN → SYN_RECV → ESTABLISHED
数据传送
连接释放
第一次挥手：FIN = 1，seq = u
第二次挥手：ACK = 1，seq = v，ack = u + 1
第三次挥手：FIN = 1，ACK = 1，seq = w, ack = u + 1
第四次挥手：ACK = 1，seq = u + 1，ack = w + 1
客户端状态 ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED
服务端状态 ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED
为什么需要三次握手？
若建立连接只需两次握手，客户端并没有太大的变化，但如果服务端在收到连接请求后就进入ESTABLISHED状态,不能保证客户端能收到自己的信息，此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。 此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。
为什么需要四次挥手？
服务端接收到客户端的关闭连接请求时可能还在发送数据，没有想要关闭数据口的意思，所以FIN与ACK不是同时发送的，而是等到服务端数据发送完了，才会发送FIN给主机客户端。
为什么客户端要先进入TIME-WAIT状态，等待2MSL时间后才进入CLOSED状态？
为了保证服务端能收到客户端的确认应答。 若客户端发完确认应答后直接进入CLOSED状态，那么如果该应答丢失，服务端等待超时后就会重新发送连接释放请求，但此时客户端已经关闭了，不会作出任何响应，因此服务端永远无法正常关闭。
