传输层两个协议 ：
在TCP/IP协议栈，传输层有两个协议TCP和UDP。
TCP 需要将要传输的文件分段、传输、 建立会话、 可靠传输、 流量控制。
UDP 一个数据包就能够完成数据通信 不分段 不需要建立会话 不需要流量控制 不可靠传输 屏幕广播 多播 广播。
常见应用层协议使用端口：
应用层协议和服务的关系
从通信和信息处理的角度看，传输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。
当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有传输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
两个主机进行通信 => 两个主机中的应用进程互相通信。
传输层的一个很重要的功能就是复用和分用。
传输层提供应用进程间的逻辑通信”。
传输层协议和网络层协议的主要区别:
传输层的主要功能:
运行在计算机中的进程是用进程标识符来标志的。
运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。这是因为在因特网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。
为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。
由于进程的创建和撤销都是动态的，发送方几乎无法识别其他机器上的进程。
有时我们会改换接收报文的进程，但并不需要通知所有发送方。
我们往往需要利用目的主机提供的功能来识别终点，而不需要知道实现这个功能的进程。
（端口号(protocol port number) 简称为端口(port)）
解决这个问题的方法就是在传输层使用协议端口号(protocol port number)，或通常简称为端口(port)。
虽然通信的终点是应用进程，但我们可以把端口想象是通信的终点，因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口，剩下的工作（即最后交付目的进程）就由 TCP 来完成。
端口用一个 16 位端口号进行标志。
端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在因特网中不同计算机的相同端口号是没有联系的。
UDP 的首部格式
用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段有 8 个字节，由 4 个字段组成，每个字段都是两个字节。
在计算检验和时，临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。
UDP 是无连接的，即发送数据之前不需要建立连接。
UDP 使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。
UDP 是面向报文的。UDP 没有拥塞控制，很适合多媒体通信的要求。
UDP 支持一对一、一对多、多对一和多对多的交互通信。
UDP 的首部开销小，只有 8 个字节。
UDP 只在 IP 的数据报服务之上增加了很少一点的功能，即端口的功能和差错检测的功能。虽然 UDP 用户数据报只能提供不可靠的交付，但 UDP 在某些方面有其特殊的优点。
TCP 面向流的概念
TCP 连接是一条虚连接而不是一条真正的物理连接。
TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。
TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）。
TCP 可把太长的数据块划分短一些再传送。TCP 也可等待积累有足够多的字节后再构成报文段发送出去。
套接字 socket = (IP地址: 端口号)
每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：
TCP 连接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
TCP协议特点
可靠通信的实现
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)。
ARQ 表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组 。
流水线传输：
停止等待协议的优点是简单，但缺点是信道利用率太低。
发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。
由于信道上一直有数据不间断地传送，这种流水线传输方式可获得很高的信道利用率。
连续 ARQ 协议 提供可靠的流水线传输
接收方一般采用累积确认的方式。
优点是：容易实现，信道利用率高。
缺点是：不能向发送方反映出接收方已经正确收到的所有分组的信息。
源端口和目的端口字段——各占 2 字节。端口是传输层与应用层的服务接口。传输层的复用和分用功能都要通过端口才能实现。
窗口扩大选项 ——占 3 字节，其中有一个字节表示移位值 S。新的窗口值等于TCP 首部中的窗口位数增大到(16 + S)，相当于把窗口值向左移动 S 位后获得实际的窗口大小。
时间戳选项——占10 字节，其中最主要的字段时间戳值字段（4 字节）和时间戳回送回答字段（4 字节）。
TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。
TCP 两端的四个窗口经常处于动态变化之中。
TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。
发送缓存用来暂时存放：
接收缓存用来暂时存放：
有关以字节为单位的滑动窗口技术，需要强调三点：
例：
TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。超时重传时间应略大于上面得出的加权平均往返时间 RTTS。
加权平均往返时间&超时重传时间
加权往返时间：第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS。
一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。
流量控制举例：
防止发送方和接收方死锁局面的产生，TCP 为每一个连接设有一个持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段，若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。
只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。零窗口推测报文段仅携带 1 字节的数据，接收方就在确认这个零窗口探测报文段时给出了现在的窗口值（接收窗口值）。
拥塞控制的一般原理：
拥塞控制是很难设计的，因为它是一个动态的（而不是静态的）问题。
当前网络正朝着高速化的方向发展，这很容易出现缓存不够大而造成分组的丢失。但分组的丢失是网络发生拥塞的征兆而不是原因。在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。
拥塞控制所起的作用：防止网络拥塞
发送方维持拥塞窗口 cwnd (congestion window)
发送方控制拥塞窗口的原则是：
慢开始：
使用慢开始算法后，每经过一个传输轮次，拥塞窗口 cwnd 就加倍。 一个传输轮次所经历的时间其实就是往返时间 RTT。“传输轮次”更加强调：把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。例如，拥塞窗口 cwnd = 4，这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这 4 个报文段的确认，总共经历的时间。
慢开始门限 ssthresh 的用法如下：
拥塞避免算法 的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。
当网络出现拥塞时
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认），就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。
然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法。
这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
“乘法减小“是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入到网络中的分组数。
“加法增大”是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口 cwnd增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。
注意：
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。
当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半，但拥塞窗口 cwnd 现在不设置为 1，而是设置为慢开始门限 ssthresh 减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
发送窗口的实际上限值：发送方的发送窗口的上限值应当取为接收方窗口 和拥塞窗口 这两个变量中较小的一个
TCP 的传输连接管理就是使传输连接的建立和释放都能正常地进行。
传输连接有三个阶段，即：连接建立、数据传送和连接释放。
TCP 连接的建立都是采用客户服务器方式。
连接建立过程中要解决以下三个问题：
两次即可建立连接，为什么还要进行第三次握手？
因为如果第一次发送连接请求因为网络原因迟到服务器，会导致服务器会处于持续等待状态，照成资源浪费。
TCP 连接必须经过时间 2MSL 后才真正释放掉。
MSL: 最长报文段寿命
