备注： 10位k、20位百万、30位g、32b-4个g
功能：提供运行在不同主机上的APP应用进程之间的逻辑通信并隐藏通信子网的细节是完整的端到端。
传输层协议在端系统(end systems )下操作
发送端：将APP数据(messages )划分为段，并传递给网络层
接收方：将每个段重组为消息并将其提交给APP应用层
应用、传输及网络层的逻辑关系(注意地址问题) ) )。
协议数据单元(PDU )的嵌套关系
(TPDU-传输层PDU )
为什么需要传输层？
1 .传输层提供的服务
连接：可靠性(TCP ) ) ) )。
面向非连接： UDP (不可靠) )
网络层服务？
为什么需要重复的传输层？
网络层：是主机hosts之间的逻辑通信
传输层：主机进程processes之间的逻辑通信，允许在主机上同时执行多个网络APP
利用和依赖网络层服务，在通信子网出现问题时可以重建端到端服务，从而增强网络层服务
传输层服务原语服务原语可被认为是一组预定义的通信例程(规范、程序、函数等)
开发者通过调用传输层服务原语构建端到端通信来隐藏各种网络层服务原语的差异
在传输层进行复用和解复用1 .复用(multiplexing )是指收集不同APP过程的数据，封装这些数据并形成对应的报头形成段(segments ) 图标
2 .解复用：将接收到的传输层段数据提交给适当的APP过程的过程
取消复用主机接收IP包的方法
每个软件包都有一个source IP address，destination IP address
每个软件包都加载一个传输层消息
每个segment包含source，destination port number；
传输层实体确定应该在端口编号中将段发送给哪个过程
(前16位：源端口号的端口号)
端口号说明
端口号说明
0~1023 :保留端口号通常提供给服务器端，由超级用户设置(可以更改，但需要批准) )。
1024~49151 :注册端口号并分配给各组织或公司以避免冲突
49152~65535 :专用端口号，可选
参考(RFC1700 ) :
33558 www.iana.org/assignments/port-numbers
Windows上的c :windowssystem32driversetcservices
在Linux/Unix下：/etc/services
说明：
同一主机上的多个进程可以同时访问服务端口。 例如，迅雷等)
无连接协议： UDP用户数据报协议
1 .是最简单的internet传输协议
2 .提供所谓的“尽力而为”服务，没有流量控制和错误控制，UDP的segments有可能是：
1 )丢失
2 )损坏
3 )不按顺序提交APP程序
3 .用于无连接的：
在收发方没有所谓的三次握手
每个UDP segment都是独立处理的，前后UDP segment互不相关
UDP头格式
(总结： UDP :不可靠、简单高效的用户数据报协议)
流多媒体(可用于APP应用程序
1 )允许丢失、时间敏感
2 )网络电台、视频点播等。 请参阅RTP
(实时传输协议(Real-time Transport Protocol ) )。
2 .其他UDP APP应用程序(C/S模式) )。
1 ) DNS(UDP.cap )、DHCP等
2 ) SNMP
3 )远程进程呼叫(RPC )。
3 .在UDP中建立的可靠传输可以在APP应用层(APP应用)得到保证
可靠的传输原理
建立连接-三次握手
释放连接(4次握手/挥手？ ）
断开传输层连接
1 .方式
不对称释放：可能会丢失数据，不采用TCP
对称释放：看连接为两个单向连接，采用询问方式。 一定能正确释放吗？
握手三次后断开连接并不能完全保证正确的释放，但一般情况下足够了
连接协议： TCP-传输控制协议TCP协议特性
1 .面向连接
2 .即使在不可靠的网络上，也可以提供可靠的端到端的字节流通信
3.能够动态的适应各种网络（拓扑）、带宽、延迟、分组尺寸等3.如果出错，应有足够的健壮性（Robustness）
4.TCP连接是建立在两个Socket（端口）之间的
5.一个TCP连接有且只能有两个端口，或者，两个端口之间只能有一个TCP连接,但一个端口（Socket）上可以有多个连接
7.TCP连接是面向字节流的，即，TCP将从上层得到的数据看作为无结构的字节流
如某进程交给TCP实体4个512B的报文，TCP发送实体可以组成如以下任意大小格式的段递交给IP层，由高层进行结构的区分（有助于提高传输效率）
4个512B的segments、2个1024B的segments、1个1448B和1个600B的segments
(每行4字节，固定的有5行，所以TCP头部至少20个字节）
TCP头部格式
1.端口号：16b，源和目的端口唯一定义一条TCP连接
2.顺序号（sequence numbe）：32b，表明本segment在字节流中的相对位置(开始位置)
3.确认号（Ack······）：32b，希望收到的下一字节序号
实验：在Wireshark中查看顺序号和确认号的变化
4.头部长度：4b，以32b（一行）为单位。TCP头部长度不固定，因此必须设置该字段，实际也指出了数据部分的开始位置
后两次间隔：捎带确认
6个标志位，一个比特
5.保留字段（Reserve，保留的，没有用）：6b，全部置0
1)URG紧急位：一般为0。当置1时，表示数据段中有紧急数据，位置从当前顺序号加上紧急指针（偏移量）开始。发送方传输层实体接到进程紧急指示后，后面收到的数据即为紧急数据，将立即发送已有的数据和紧急数据(不再继续累积数据)，且到达后接收方立刻中断，将紧急数据提前提交上层应用程序。
2)ACK确认号位：置1表示确认号有效；否则忽略确认号字段。用于连接请求时的第一次握手（第一次握手为0）
3)PSH推位：置1，表示数据段是被“推”过来的，即发送方正在等待一些字节以形成段时突然得到应用程序的Push指令，将立即把此时缓存中的数据形成段，马上递交给IP层（一般在连接好后的第一个请求包置PSH为1）（一般为0）
4)RST恢复位：置1，可用于表示数据段非法（如确认号不对），拒绝（Reject）不正确的连接请求确认等。一般而言，如你接收到了一个RST位为1的段，表明你这方出现了问题。（谁收到谁就有问题，拒绝连接）
5)SYN同步位：一般为0。置1时只用在连接建立时的3次握手中的前2次，即用于连接双方互相通知顺序号，初始化一个连接。如：（syn=1,seq=1234,ack=0）的段表示连接请求
（syn=1,seq=6789,ack=1235）的段表示连接请求确认
6)FIN结束位：置1时用于释放连接，发送方告知接收方已无数据要发送或请求方不再请求数据（现在基本都是4次握手释放）
如：
6.窗口尺寸：16b，接收方告诉发送方：
(确认号-1)之前的字节已经正确接收，还可最多发送这么多字节。
如果为0，表示(确认号-1)之前的字节已正确接收，但希望暂停发送；其后再发送一个有相同确认号但窗口尺寸非0的段告诉发送方恢复传输
7.选项：必须32b的整数倍，一般在连接建立时，如：
1)协商MTU(最大传输单元）。注意：传输层的MTU即MSS（Maximum Segment Size）仅为数据部分，多为1460B（为什么？1460=1500-20-20）
2)协商窗口尺寸因子：由于窗口尺寸为16b，因此最大为64KB。对于特定情况（如1000Mbps但线路延迟100ms且双方方有足够的缓存）应根据线路的状态和发送方及接收方的情况动态的改变窗口尺寸使得其可以大于64KB（左移因子，最yxdqq将窗口尺寸从16b扩大为30b），以提高线路利用率
3)协商重发方式：选择性或全部。缺省为选择性重发（SACK）
TCP的一些策略
1.发送方收到接收方窗口大小为0的段时
一般不能再发送数据，除下列情况
1).当有紧急数据时可以发送
2)如在一定时间内，仍未收到恢复发送的段，可以发送1B的段，以此防止当到来的窗口声明包丢失时的死锁。
2.发送方一般不会当应用进程一提交数据就马上组段发送
1)当前多数TCP应用都采用：如应用进程提交了数据，先发送1B的段，其余的数据应等到累积到窗口尺寸的一半或MTU时再发送
2)或遇到紧急数据
3.接收方一般也不会连续发送ACK
一般都延迟500ms以希望能捎带
4.接收方的接收窗口已告知发送方为0后，其后空出了少量的空间如100B，一般不立即发送窗口尺寸修正信息给发送方
1)一般在空余了窗口尺寸的一半或MTU后才报告，尽可能避免小数据段在网络上的传输
5.如窗口尺寸需要大于64KB，则利用option中的Window Scale比例因子协商，可左移14b，达到1GB
最佳接收窗口尺寸
1)太小，瓶颈在主机；太大，网络和主机可能都是瓶颈
2)实际中，一般窗口尺寸将被设置为MTU（如1460B）的偶数倍
TCP的一些漏洞
1.Flag攻击
TCP报文标志位包括URG、ACK、PSH、RST、SYN、FIN。攻击者通过发送非法TCP flag组合的报文，受害主机收到后进行判断识别，消耗其性能，甚至会造成有些操作系统报文处理异常，主机崩溃。
2.Land攻击（环回攻击）
攻击者向受害者发送源IP/端口和目的IP/端口地址都为受害者的IP地址/端口的报文。这将导致受害者向它自己的地址发送SYN-ACK回应报文，结果这个地址又发回ACK消息并创建一个空连接。从而造成资源的消耗。
3.DDOS攻击
利用TCP的3次握手漏洞。Mitnick的攻击
如何防范？（p.168~169）
1.拥塞的产生
当加载到一个网络的负荷超过其处理能力时
2.传输层拥塞控制的重要性
1)尽管网络层也进行拥塞控制，但拥塞的产生的根本原因是由于端系统（资源子网）向通信子网加载了过量的负荷引起，因此仅由网络层（通信子网）的拥塞控制不能解决，必须由端到端传输的传输层来参与解决。
2)最直接的方法是降低数据传输率（谁？如何？）
3.如何判断拥塞发生
如果发生超时，一般有两种可能（除物理线路故障）
1)分组可能由于噪音丢失，很少出现（除无线网络）
2)发生了拥塞，滞留于子网或被子网丢弃
因此，当前的TCP算法都假设超时由拥塞引起
Internet拥塞控制算法
1.发送方需维护（知道）2个窗口
1)接收窗口：表明接收方容量
2)拥塞窗口：表明网络容量
2.选择两者的最小值作为可以最多发送的字节数
注意与MTU区分开
3.建立连接时，发送方可以
1)获知接收窗口尺寸
2)以MTU初始化拥塞窗口，典型的如1460B
随后，发送方发送一个尺寸为MTU的数据段
如果在Timeout前得到确认，将拥塞窗口更改为原来的2倍，接下来发送2个MTU尺寸的数据段（能超过MTU？）
如果在Timeout前获得确认，再将拥塞窗口尺寸更改为原来的两倍，接下来发送4个MTU尺寸的数据段
以此类推，直到达到接收窗口尺寸（肯定不能超过？这也是接收窗口一般为MTU偶数倍的一个原因）或出现了Timeout
如果此时没有出现Timeout，则维持该尺寸的拥塞窗口
如果出现了超时，则从头开始刚才的算法
以上称为慢启动（Slow Start）拥塞控制法
实例
在目前的Internet拥塞控制中还引入了一个参数：临界值（阈值，threshold），一般初始化为32KB
规定
当拥塞窗口增加到临界值后，不以指数而以线性方式增加
如发生Timeout，临界值更改为当前拥塞窗口的一半
进一步阅读*：
TCP的缺点（QUIC）
其它拥塞控制算法：RENO、CUBIC、BBR等