传输层功能：提供进程之间的逻辑通信，对收到的报文进行差错检验
传输层协议：TCP和UDP
TCP（Transmission Control Protocol 传输控制协议）
用于控制对报文的分段处理，适用于大文件的传输，如文件的上传下载、电影下载、邮件发送等场景；
TCP传输的特点：需要与服务器建立连接(面向连接，三次握手)，保证可靠传输，可以进行流量控制，提供全双工通信(打电话)，面向字节流，只能是点对点的传输
TCP连接的端点不是主机、IP地址、应用程序或者传输层协议端口，而是套接字(Socket)，由IP地址加上端口号构成
TCP首部：固定20字节加可变长度
格式：源端口(2)——目的端口(2)
——序号(4，数据报中第一个字节在整个数据报中的序号)
——确认号(4，数据报中最后一个字节的序号加一)
——数据偏移(4bit，表示从数据偏移*4个字节开始时数据，所以TCP首部最大为60字节)
——保留(6bit)——URG(标记为1时优先发送，不需要排队)——ACK(如果为0确认号为0，例如建立连接等请求时)——PSH(如果设为1，则直接将该段数据发在接受方缓存的最前端)——RST(如果为1代表发生异常中断，需要重新连接)——SYN(发送和确认会话时设置为1)——FIN(释放连接时值为1)——窗口(2，接受缓存的大小，字节为单位)
——校验和(2，和UDP计算方式一样，但是需要该协议号为6)——紧急指针(2，紧急数据的尾部)——可变长度(可有可无，可以通知最大数据报的大小)——填充(4字节的倍数)
SYN攻击，虚造大量IP地址与计算机建立连接
Land攻击，让自己与自己建立大量连接
TCP如何实现可靠传输
停止等待协议
简单但是信道利用率低
自动重传请求(Automatic Repeat reQuest)
流水线传输
发送发维持发送窗口(数据报个数)，发送窗口中的数据包可以连续发送，收到确认后向前移动一格
以字节为单位的滑动窗口传输
超时重传：TCP每发送一段报文，就会对这段报文设置一个计时器，直到计时器的重传时结束还没有收到确认就会重传这一段报文
超时重传时间计算：新RTTs = (1 - a)旧的RTTs + a(新的RTT样本)
TCP如何进行流量控制
在接受方发送确认消息时，同时发送调整窗口的大小，为防止发送端一直等待，发送端也会定时发送试探消息
TCP的拥塞控制
满开始算法：试探性发送，初始从一个数据报开始发送，逐渐翻倍，直到默认慢开始门限，然后递增加一，若发现丢包，则重新计算慢开始门限，为当前值的一半，然后又从一个数据报开始发送(废弃了)
快恢复：发现丢包后，接受方连续发送3个确认给发送方，如果三个确认都收到了的话就直接从新的门限开始递增，而不是从一开始
TCP的传输连接管理
采用客户服务端方式，主动发起请求的应用进程叫做客户端，被动等待请求的进程叫做服务端
三次握手建立连接
第一次：客户端——服务端 SYN = 1；ACK = 0 状态：客户端——SYN_SEND 服务端——LISTEN
第二次：服务端——客户端 SYN = 1；ACK = 1 状态：客户端——ESTABLISHED 服务端——SYN_RECEIVED
第三次：客户端——服务端 ACK = 1；SYN = 0 状态：客户端——ESTABLISHED 服务端——ESTABLISHED
为什么要第三次握手？
防止在第一次握手时客户端发送多次请求(发送延迟，客户端以为发送失败所以重发)，服务端收到后返回多个确认，而客户端只确认一个连接，造成服务端一直等待其他多余的连接；所以通过客户端再次确认后服务端才与之建立连接，如果迟迟没有收到确认就不继续等待
TCP连接释放
四次挥手
第一次：客户端——服务端 FIN = 1；客户端不再主动向服务端发送数据 状态：客户端——FIN_WAIT-1 服务端——ESTABLISHED
第二次：服务端——客户端 ACK = 1；服务端继续向客户端发送ACK确认收到消息 状态：客户端——FIN_WAIT-2 服务端——CLOSE_WAIT
第三次：服务端——客户端 FIN = 1；服务端不再向客户端发送数据 状态：客户端——FIN_WAIT 服务端——LAST_ACK
第四次：客户端——服务端 ACK = 1；客户端发出确认消息 状态：客户端——TIME_WAIT 服务端——CLOSE
经过两个MSL(一般是两分钟)后，客户端才会关闭
为什么建立连接只需要三次握手，而释放连接却需要4次挥手？
建立连接时，服务端处于监听状态，收到请求后SYN和ACK可以一起发送，而断开连接时，因为服务端可能不会立即关闭，所以只能先回复ACK确认，等需要的数据传输完成后再发送FIN关闭消息，因此比建立连接时多一步
为什么客户端TIME_WAIT后还需要等待2*MSL后才能关闭？
防止客户端最后的ACK确认消息丢失，所以等待两分钟(如果服务器等待一段时间后没有收到确认消息，会再次发送FIN消息)
UDP （User Datagram Protocol 用户报文协议）
一个数据包就能完成传输，适用于小文件的传输，如QQ消息、DNS解析等场景；无连接，不保证可靠传输、不能进行流量控制、没有拥塞控制、首部很小只有8个字节，可以是一对多传输
UDP的首部格式
源端口——目的端口——UDP数据报长度——校验和，每个部分均占两个字节，计算校验和时需要加上伪首部(12个字节，网络层首部)；校验值通过伪首部加UDP数据报的二进制以两个字节为基础进行反码求和，再求反码得到
传输层协议与应用层协议之间的联系
应用层协议 = 传输层协议 + 端口号
例如：http = TCP + 80；https = TCP + 443；RDP = TCP + 3389(远程控制)；ftp = TCP + 21；DNS = UDP + 53；SQL = TCP + 1433等
应用层与服务之间的联系
服务通过与之对应的协议类型和端口号来侦听来自客户端的请求
例如：web----TCP + 80
客户端通过IP地址来连接服务器，通过协议和端口号来连接具体服务
端口的分类 两个字节
熟知端口：0~1023；例如http、https
登记端口：1024~40151
客户端端口：49152~65535
常用网络命令：
netstat -n 显示与客户端建立的对话
netstat -nb 显示建立会话的具体进程
netstat -an 显示正在监听的端口
telnet ip地址 [端口号] 测试该ip地址的指定端口号是否可以连接，端口号默认为23