TCP和UDP（含三次握手、四次挥手）

用户数据报协议UDP的主要特点：
1、UDP是无连接的，即发送数据之前不需要建立连接。
2、UDP使用尽最大努力交付，即不保证可靠交付。
3、UDP是面向报文的，发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。
4、UDP没有拥塞控制。
5、UDP支持一对一、一对多、多对一、多对多的交互通信。
6、UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。
传输控制协议TCP的主要特点：
1、TCP是面向连接的运输层协议。
2、TCP提供可靠交付的服务。
3、TCP提供全双工通信。

套接字socket=(IP地址：端口号)

TCP发送的报文段是交给IP层传送的。但ip层只能提供尽最大努力服务，也就是说，tcp下面的网络提供的是不可靠的传输。
因此tcp必须采取适当的措施才能使得两个运输层之间的通信变得可靠。
理想的传输条件有以下两个特点：
1、传输信道不产生差错。
2、不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
然而实际的网络都不具备以上两个理想条件。但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，
同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。这样一来，本来是不可靠的传输信道就能够实现可靠传输了。

停止等待协议
停止等待就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

使用确认和重传机制，我们可以在不可靠的传输网络上实现可靠的通信。

可靠传输协议常称为自动重传请求ARQ。为什么叫自动重传？
因为重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。

停止等待协议的优点是简单，但缺点是信道利用率太低。
为了提高效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。
流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。
这样可使信道上一直有数据不间断地传送。

当使用流水线传输时，就要使用下面介绍的连续ARQ协议和滑动窗口协议。

连续ARQ协议
连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般都是采用累积确认的方式。

tcp的流量控制
利用滑动窗口机制可以很方便地在tcp连接上实现对发送方的流量控制。

拥塞控制与流量控制的关系密切，它们之间也存在着一些差别。所谓拥塞控制就会是防止过多的数据注入到网络中，
这样可以使网络中的路由器或链路不致过载。
流量控制往往指点对点通信量的控制，是个端到端的问题。流量控制所要做的就是抑制发送端发送数据的速率，
以便使接收端来得及接收。

几种拥塞控制方法
进行拥塞控制的四种算法：慢开始、拥塞避免、快重传和快恢复。
为了集中精力讨论拥塞控制，我们假定：
1、数据是单方向传送，而另一个方向只传送确认。
2、接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定。

发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞控制的大小取决于网络的拥塞程度，并且动态地在变化。
发送方让自己的发送窗口等于拥塞窗口。以后我们就知道，如果再考虑接收方的接收能力，那么发送窗口还可能小于拥塞窗口。

慢开始算法由小到大逐渐增大拥塞窗口数值。在一开始发送方先设置cwnd=1，每经过一个传输轮次，拥塞窗口cwnd就加倍。

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh，
当拥塞窗口小于慢开始门限时，使用慢开始算法。
当拥塞窗口大于慢开始门限时，停止使用慢开始算法而改用拥塞避免算法。
当拥塞窗口等于慢开始门限时，即可以使用慢开始算法，也可以使用拥塞避免算法。

拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认），就要把慢开始门限
设置为出现拥塞时的发送方窗口值的一半。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速
减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

快重传和快恢复
快重传算法要求接收方每收到一个失序的报文段后就立即发出重复确认而不要等待自己发送数据时才进行捎带确认。
快恢复把cwnd值设置为慢开始门限减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

tcp的是面向连接的协议
连接有三个阶段：
1、连接建立 2、数据传送 3、连接释放
tcp连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。

客户A，服务器B
B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，
等待客户的连接请求。如有，即作出响应。
A的TCP客户进程也是首先创建传输控制块TCB，然后向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个
初始序号seq=x。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。
B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack=x+1，
同时也为自己选择一个初始序号seq=y。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。
TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1。
这时，TCP连接已经建立，A进入ESTABLISHED(已建立连接)状态。

当B收到A的确认后，也进入ESTABLISHED状态。
上面给出的连接建立过程叫做三次握手。
为什么A还要发送一次确认呢？这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。  

TCP的连接释放
数据传输结束后，通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态。A的应用进程先向其TCP发出连接释放报文段，
并停止再发送数据，主动关闭TCP连接。
A把连接释放报文段首部的终止控制位FIN置1，其序号seq=u，这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。

B收到连接释放报文段后即发出确认，确认号是ack=u+1，这个报文段自己的序号是v，然后B就进入CLOSE-WAIT（关闭等待）状态，
这时，如B发送数据，A仍要接收。
A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。B需要重复上次已发送过的确认号
ack=u+1。这时B就进入LAST-ACK（最后确认）状态，等待A的确认。（假定此时B的序号为w）
A在收到B的连接释放报文段后，必须对此发出确认，在确认报文段中把ACK置1，确认号ack=w+1，而自己的序号是seq=u+1（根据TCP标准，
前面发送过的FIN报文段要消耗一个序号）。然后进入到TIME-WAIT（时间等待状态）。注意，现在TCP连接还没有释放掉。必须经过时间等待
计时器设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命。

为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，如果丢失，B会超时重传FIN+ACK报文段。

B只要收到了A发送的确认，就进入CLOSED状态。

上述的TCP连接释放过程是四次握手。

SYN：同步序列编号（Synchronize Sequence Numbers）。是TCP/IP建立连接时使用的握手信号。
seq和ack号存在于TCP报文段的首部中，seq是序号，ack是确认号，大小均为4字节。
ACK表示响应

SYN表示建立连接，FIN表示关闭连接