根本目的：在网络层提供的数据通信服务基础上，实现主机的进程间通信的可靠服务
三大要点：
为位于两个主机内部的两个应用进程之间提供通信服务传输层协议软件属于OS操作系统内核软件而非用户软件提供可靠的通信服务“套接字”表示一个IP地址与对应的一个进程标识（端口号）。例如，一个IP地址为202.1.2.5客户端使用3022端口号，那么标识客户端的套接字为“202.1.2.5:3022”。
端口号为0-65535之间的整数，有3种类型：熟知端口号、注册端口号、临时端口号。
熟知端口号：给每种服务器分配确定的全局端口号。每个用户进程都知道相应的服务器进程的熟知端口号，范围为0-1023，它是统一分配和控制的。
注册端口号：在IANA注册的端口号，数值范围为1024-49151。
临时端口号：客户端程序使用临时端口号，它是运行在客户端上的TCP/IP软件随机选取的，范围为49152-65535。
一个完整的进程通信标识需要一个五元组标识：(协议、本地地址、本地端口、远程地址、远程端口号)
如：( 协议=tcp, 本地地址=192.168.0.7, 本地端口=54470, 远程地址=172.217.6.127, 远程端口=443 )
意指：运行TCP/IP协议主机中，可以同时运行不同应用层协议和不同的应用程序。
由传输层根据不同的TPDU（传输协议数据单元）的端口号，区分出不同属性，分别传给对应的几个应用进程。
无连接的：发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
尽最大努力交付：即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
面向报文的：UDP 对应用层传递下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP 对于应用程序提交的报文，添加头部构成TPDU后就向下提交给IP层。
没有拥塞控制：网络出现的拥塞时，UDP不会使源主机的发送速率降低。这对某些实时应用是很重要的，很适合多媒体通信的要求。
支持多对多的交互通信
首部开销小：只有 8 个字节，比 TCP 的 20 个字节的首部要短
UDP总长度(单位为字节) = 8 (UDP报头长度) + 数据字段的字节长度 (长度必须为2字节的倍数，即为偶数)；
数据字段的字节长度必须为2字节的倍数原因是：校验和的计算是以2字节为单位的；
UDP的检验和是可选的，根据自己对效率、可靠性的要求来决定是否使用。
伪报头来自于IP报头，只在计算检验和时起作用，既不向低层传输，也不向高层传送。
计算检验和的方法：初始设置“检验和”字段为全0，对蓝色框起的内容，以2字节（16位）为单位进行累加，如果最高位发生进位，则最后的结果加1，最后的累加和再取反码就是检验和，计算出检验和之后将其插入“检验和”字段。
接收方判断数据传输是否正确的方法：同样对接收到的蓝色框内的内容计算检验和，并取反码，如果取反码为0，说明数据传输正确。
面向连接的传输服务。打电话式、会话式通信
面向字节流传输服务（而UDP是面向报文）。字节管道、字节按序传输和到达
全双工通信。一个应用进程可以同时接收和发送数据、捎带确认；通信双方都设置有发送和接收缓冲区，应用程序将要发送的数据字节提交给发送缓冲区，实际发送由TCP协议控制，接收方收到数据字节后将它存放在接收缓冲区，等待高层应用程序读取。
可建立多个并发的TCP连接。如Web服务器可同时与多个客户端建立的连接会话
可靠传输服务。不丢失数据、保持数据有序、向上层不重复提交数据（通过确认机制、拥塞控制等方式实现）， 想像一下ATM机转帐应用就需要上述可靠性
应用进程发送的多个数据块，首先进入TCP发送缓冲队列。然后, TCP按照算法，每次从发送缓冲队列取出特定长度的一组字节，组成一个segment(报文段)作为TCP的传输单元，发往接收方。
TCP报头长度为20-60字节，其中固定部分长度为20字节。
结构如下：
（1）发送序号（Seq.number）：若SYN=1,该字段表示TCP数据字段的第1个字节A在当前发送信道T中的初始序号；若SYN=0, 表示A在T中的序号(大于初始序号)。
（2）确认序号（Ack.number）：只有当ACK位=1时有效,表示发送此报文段的进程期望接收的第一新字节的序号，属于捎带确认方法。
（3）报头长度：以4字节为一个计算单元，值在5（5*4=20）至15（15*4=60）之间。
（4）控制字段标志：如下图所示
（5）窗口：接收方通知即将发送报文的发送方下一个报文中最多可以发送的字节数，窗口字段的值是动态变化的。
（6）检验和：与UDP计算相同，不过在UDP中是可选，在TCP中检验和是必选的。
TCP规定报文数据部分的最大长度称为最大段长度（MSS），MSS的具体值需要考虑以下方面：
协议开销IP分段发送和接收缓冲区的限制MSS的默认值为536字节，可以在建立连接时选择其它的MSS值。
TCP连接包括连接建立、报文传输、连接释放。
（1）当客户端准备发起一次TCP连接，首先向服务器发送第一个“SYN”报文（控制位SYN=1）。
（2）服务器收到SYN报文后，如果同意建立连接，则向客户端发送第二个“SYN+ACK”报文（控制位SYN=1，ACK=1）。该报文表示对第一个SYN报文请求的确认，同时给出了窗口大小。
（3）接收到SYN+ACK报文后，客户端发送第三个ACK报文，表示对SYN+ACK报文的确认。
如下图：
实例如下：
第2个报文段有两个作用：A) 对第1个SYN报文的确认 B) 通知Site1，Site2的初始序号为Seq=0，并让site1下次从序号1开始发送。尽管SYN报文的数据字段长度=0(图中Len=0)，但SYN报文仍需要消耗1个序列号，即用于建立连接的第2个报文段的ACK=第1个报文段的Seq + 1；同理第3个报文段的ACK=第2个报文段的Seq + 1。当TCP连接成功建立后，客户端的应用进程和服务器端的应用进程就可以使用这个连接，进行全双工的字节流传输。
具体过程见我的这篇博客。
例：
尽管有时FIN报文的数据字段长度=0(图中蓝色框Len=0)，但FIN报文仍需要消耗额外1个序列号，因此: 最后一个报文段.ACK= 第3个报文段.Seq + Len + 1(FIN) = 2；同理，第2个报文段.ACK = 第1个报文段.Seq +第1个报文段.Len(数据长度) + 1 (FIN) = 8194至于为什么SYN和FIN报文要消耗额外1个序列号，见此链接。
TCP的4个定时器：重传定时器、坚持定时器、保持定时器、时间等待定时器
保持定时器（激活定时器）
用来防止TCP连接长时间处于空闲状态时间等待定时器
连接终止期间使用，TCP关闭连接，并不马上真正关闭，在时间等待期间，连接处于一种过渡状态（TIME_WAIT）详细版见此博客
作用：
差错控制和流量控制基本概念：
发送方缓存：用于存储准备发送的数据发送窗口：窗口值不为0，可以发送报文段接收方缓存：将正确接收的字节流写入缓存，等待接收读取接收窗口：窗口值=接收缓存可以接收的字节流字节流分段，按段传输，捎带确认（确认号）通过滑动窗口跟踪、记录发送状态，实现差错控制tcp发送缓冲区中的数据是带tcp首部的吗？ 不带
下图中的序号都是字节序号：
回退方式
假设丢失了第2个报文段，不管之后的报文段是否已正确接收，从第2个报文段的第1个字节序号151开始，重发所有的4个报文段。显然，效率低下。选择重发方式
接收方收到不连续的字节时，如果这些字节的序号都在接收窗口之内，则首先接收缓存这些字节，并将丢失的字节流序号通知发送方，发送方只需重发丢失的报文段，而不需要重发已经接收的报文段。发送一个报文段，设置定时器，同时将其副本放入重传队列。
计算重传时间Timeout：
其中，
Rtt’: 现在估算的往返时间Rtt: 估计的往返时间，上一个往返时间估计值Rts: 往返时间样本，实际测出的前一个报文的往返时间α:常数权重因子，设定旧的Rtt和新的Rts对新的Rtt’的影响能力 RFC 2988 推荐的 α值为 1/8，即0.125。让Rtt’跟随样本β : 超时常数加权因子，推荐值=2目的：由发送方控制发送速率，使之不超过接收速率，防止接收方来不及接收字节流，而出现报文丢失现象。
流量控制过程：
接收方从缓存中读取速度大于等于字节到达速度，接收方在每个确认中发出一个非零窗口通告。如果发送方发送速度比接收方读取速度快，将造成缓冲区被全部占用，之后到达的字节因缓冲区溢出而丢弃。此时，接收方必须发出一个“零窗口”的通告，告知当发送方停止发送（直到接收“非零窗口”通告为止）。接收方需要根据自己的接收能力给出一个合适的接收窗口，并将它写入TCP报头中，通知发送方。坚持定时器
接收方发出了“零窗口”通告之后，发送方停止发送，直到接收方再发出“非零窗口”通告为止。问题：如果“非零窗口”通告丢失，发送方将无休止地等待接收方通知，才能继续发送报文段，造成死锁。解决：设置“坚持定时器”。发送方收到“零窗口”通告为零的确认时，启动“坚持定时器”。 坚持定时器时间到时，发送方发生探测报文（提示接收方，确认已丢失，必须重传）。传输效率问题
（情况1） 假设数据以每次1B的方式进入发送方，效率会很低，这时需要提高传输效率的Nagle算法：
当数据以每次1B的方式进入发送方时，第1次发送方只发送1B，其他的字节存入缓冲区。当第1个报文段被确认，再把缓冲区中数据放入第2个报文段中发送，这样一边发送/等待确认，一边缓存待发送数据（可有效提高传输效率）。当缓存的数据字节数达到发送窗口的1/2（接近MSS），立即将它们作为一个报文段发送。（情况2）糊涂窗口综合征：当接收端应用进程处理接收缓冲区数据很慢，就会使应用进程间传送的报文段很小，特别是有效载荷很小； 极端情况下，有效载荷可能只有1个字节；传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象。
Clark算法解决思想：
禁止接收方发送1B的窗口更新报文，让接收方等待一段时间，使接收缓存有足够的空间接收一个较长的报文段。如果通知窗口长度足够容纳一个MSS的报文段或者达到总缓冲空间的一半时，再发送窗口更新报文。接收方等待一段时间对发送方也有好处（积累一定长度的数据字节，发送长报文也有利于提高传输效率）。作用：防止过多报文进入网络造成路由器与链路过载情况出现。
网络出现拥塞的条件：∑对网络资源的需求 > 网络可用资源
实现拥塞控制最基本手段：TCP滑动窗口技术。发送数据，既要考虑接收能力，又要避免网络发生拥塞发送窗口计算：发送窗口 = Min（通知窗口，拥塞窗口 ）通知窗口rwnd：接收方允许接收的能力，来自接收方流量控制（将“通知窗口”值放在TCP报头中，传送给发送端）。拥塞窗口cwnd：发送方根据网络拥塞情况得出的窗口值，来自发送方的流量控制。未发生拥塞情况下，接收方“通知窗口”和“拥塞窗口”是一致的确定拥塞窗口大小方法：慢开始、拥塞避免、快重传、快恢复
慢开始方法思想
开始发送数据时，用试探方法，由小到大逐步增大cwnd值，以二进制指数方式慢速增长（2^n）。慢开始阈值SST：为避免拥塞窗口增长过快引起网络拥塞
当cwnd<SST时，使用慢开始算法。当cwnd>SST时，停止使用慢开始算法，使用拥塞避免算法。当cwnd=SST时，既可以使用慢开始算法，也可使用拥塞避免算法。若出现超时，发送方将SST值设置为cwnd/2拥塞避免算法
当cwnd>SST时，停止使用慢开始算法，转而使用拥塞避免算法每增加一个往返就将cwnd值+1，拥塞窗口呈线性增加规律缓慢增长若出现超时，发送方将SST值设置为cwnd/2，并让拥塞窗口cwnd重新回到1与快重传配合使用的还有快恢复算法，其过程有以下两个要点：
当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意：接下去不执行慢开始算法。由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。下图给出了快重传和快恢复的示意图，并标明了“TCP Reno版本”。（旧的TCP Tahoe版会进入慢开始，新的 TCP Reno 版本在快重传之后采用拥塞避免算法而不是采用慢开始算法。）
下图是完整的过程：
