1、网络层提供主机之间的逻辑通信，运输层提供的的是应用进程间的逻辑通信。 2、运输车层对报文的差错检测，网路层只有对IP首部的检测 3、传输层的主要协议：TCP UDP。故传输层 不一定是面向连接的
运输层的复用和分用
复用：多个应用进程都可以同时通过传输层进行通信 ，
分用：运输层从IP层收到数据后分发给各应用进程
应用应用层协议运输层协议DNSUDPTFTPUDPRIP（路由信息协议）UDPDHCPUDP网络管理SNMPUDP远程文件服务器NFSUDPIP电话UDP流式媒体UDPSMTPTCP TELNETTCPHTTPFTP通信时不仅要知道IP地址，还要知道端口号（用于寻找相应的进程）。
TCP IP 16位端口号：
0-1024：服务端使用的端口号
1024-49151：登记端口号
49152-65535：客户端使用的端口号
特点： 1、无连接 2、不可靠 3、面向报文 4、没有拥塞控制 5、支持一对一、一对多、多对一和多对多的通信 5、UDP首部小，8个字节 UDP首部：源端口、目的端口、长度、检验和，各占2个字节 UDP校验和方法：用到12个字节的伪首部，二进制反码和放入校验和字段，发送之后在目的端检验是否相等。
特点： 1、面向连接 （它的连接是一条虚连接） 2、点对点 3、可靠 4、全双工 5、面向字节流
20字节的固定首部（没有选项时）
1、源端口和目的端口 各占2个字节 2、序号 4字节 每个字节都按顺序编号 3、确认号 4字节 4、数据偏移 4位 指明数据起始处对于报文段起始处的偏移大小，即首部大小最大15*4=60字节 5、保留 6位 6、URG 紧急指针位 ACK 此位为1 确认号才有效，连接后所有报文段都置1 PSH 推送操作 RST 严重差错，断开连接，复位 SYN 置1表示这是一个连接请求 FIN 请求释放连接 7、窗口 2字节 本发送报文段的接收窗口，告诉对方，从确认号开始自己还可以接受的最大数据量 8、校验和 2字节 检验首部和数据，和UDP类似，只不过伪首部中的第四个字段17改为TCP的协议号6 9、紧急指针 2字节 指出紧急数据的字节数 10、选项 长度可变 最多40字节，有MSS、窗口扩大选项、时间戳（可用来计算RTT）、选择确认选项； 11、填充
MSS：数据段的最大长度，默认536字节，MSS太小利用率不高，太大IP层还得分片。
往返时间：RTT 时延
TCP连接的端点是套接字：IP地址加端口号
TCP可靠传输的工作原理
停止等待协议： 若发送方位A，接收方为B。每次发送方发送一个分组等待B确认后才再次发送。 出现差错呢？就涉及到了超时重传，每次发送后需要设置一个计时器，等待一段时间没有收到确认后，再次发送。这里涉及一下三点： 1、A每次发送后，必须保存已发送的副本，收到确认后清楚 2、分组和确认分组都要有编号。 3、超时计时器的时间必须比数据往返的时间要长。这个时间如何确定。 若确认丢失，或迟到？自己想一下就知道了。自动重传请求ARQ 停止等待信道利用率太低。于是就出现了： 连续ARQ协议： 一个发送窗口，每收到一个确认，就将窗口向前移动； 滑动窗口协议：
滑动窗口 : 点对点通信量的控制，所做的是抑制发送端发送数据的速率，是一个端对端的问题，即只要考虑对方发送的数据即可。
拥塞控制：防止过多的数据注入网络，使网络中的路由器或链路不致过载
拥塞：\sum 对资源的需求 > 可用资源
采用的四种算法：
拥塞窗口cwnd，发送方一般让自己的发送窗口=拥塞窗口，当然也要取决于对方的接收窗口。
慢开始：开始时，cwnd=一个MSS(最大报文段长度)，每次收到对方确认，cwnd+1，即每经过一个传输轮次(即收到最后一个确认号)，cwnd翻倍。慢开始算法有一个慢开始门限K，当cwnd小于K时，采用慢开始算法，大于K时采用拥塞避免算法。
拥塞避免算法：没收到一个确认让cwnd加一（一个MSS），而不是加倍。每当判断出发生拥塞时，慢开始门限减半，CWND设为一。
快重传：接收方收到失序报文，立即重复发送确认，当发送方收到三个确认后立即重传待发送报文段。
快恢复：当发送方收到三个确认后，立即执行乘法减小算法，将慢开始门限减半，但接下来不执行慢开始算法而是将cwnd变为和慢开始门限相同的数值（也可能是咋此基础上+3*MSS），执行拥塞避免算法。
采用客户端服务器
三次握手：
1、开始时处于CLOSED状态，服务端（B）创建TCB传输控制块，进入LISTEN状态。A创建TCB，发出请求报文段，SYN=1，序号seq=x，TCP规定，SYN报文段不能携带数据，但消耗序号，客户进程进入SYN-SENT（同步已发送状态）
2、B收到连接请求报文段，如同意，SYN和ACK位置1，确认号ack = x+1，选择初始序号seq = y， 不能携带数据，服务器进程进入SYN-RCVD状态
3、客户进程收到确认后，再次给B确认，ACK置1，确认号ack=y+1，序号seq = x+1，客户进入ESTABLISHED状态。
为什么要三次呢？防止已失效的链接请求报文段突然又传到B，那么B发出确认连接消息后，就一直等待A的消息，而A不鸟B的确认，故一直占用B的资源，造成浪费!
A和B都处于ESTABLISHED状态，
1、A应用进程先向TCP发出连接释放报文段，并停止发送数据，A将FIN置1，序号seq=u（前面已传送的数据最后一个字节序号加1），此时A进入FIN-WAIT（终止等待1）
2、B发送确认号ack=u+1，seq=v，B进入CLOSE-WAIT（关闭等待状态），A到B方向的连接释放，TCP处于半关闭状态。A收到B的确认后，进入FIN-WAIT-2状态
3、B发送完数据后，通知TCP释放连接，发送报文段，FIN=1，B序号w，重复上次确认号ack=u+1，B进入LAST-ACK状态，等待A的确认。
4、A收到消息，置ACK=1，确认号ack = w+1，自己的序号u+1（据TCP标准，前面发送的FIN报文段消耗一个序号），进入TIME-WAIT状态。在等待2MSL时间后进入CLOSED状态。
MSL：最长报文段寿命。
等待2MSL时间的原因：1、保证A发送的最后一个ACK报文段能够到达B，若B没有收到处于LAST-ACK状态的B会重发FIN报文，A收到后重发确认，并重新计时2MSL。
2、防止已失效的连接请求报文段出现在本连接中
