1.TCP UDP区别
| TCP | UDP | |
|---|---|---|
| 是否面向连接 | 面向连接 | 非面向连接 |
| 传输可靠性 | 可靠 | 不可靠 |
| 应用场合 | 传输大量数据 | 少量数据 |
| 速度 | 慢 | 快 |
| 使用场景 | se | se |
2.三次握手四次挥手
描述： 3次握手就是说客户端和服务器建立tcp连接时需要发送3个包
为什么是3次不是2次：防止已失效的连接请求报文段突然又传送到了服务端产生错误
- 比如说客户端发出的第一个连接请求报文段并没有丢失，只是滞留了，但是之后又到达服务器端。服务器端收到这个失效的连接请求报文段后，误认为是客户端再次发送的一个新请求。就发出确认报文同意建立连接。如果不用“三次握手”，那么只要服务器发出确认包，新的连接就建立那么由于现在服务器端没有发出建立连接的请求，素以不会管服务器的确认包，也不会向服务器发数据。这样服务器以为客户端会发数据，资源就被浪费了
- 四次挥手概念：
*
- 为什么是4次挥手：
因为TCP有个半关闭状态，假设A.B要释放连接，那么A发送一个释放连接报文给B，B收到后发送确认，这个时候A不发数据，但是B如果发数据A还是要接受，然后B还要发给A连接释放报文，然后A发确认，所以是4次。
3.滑动窗口协议算法？
4.TCP流量控制
- 原因：：如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失
- 原理：是利用滑动窗口实现的 ，接收方告诉发送方自己的接收窗口大小，然后发送方发送窗口不能超过接收方给出的接收窗口值
5.TCP拥塞控制：
- 原因：过多的数据发送到网络中使得路由器或者链路过载
- 方法：慢开始，拥塞避免，快重传，快恢复
- 原理：
- 慢开始和拥塞避免 发送方维持一个拥塞窗口 cwnd ( congestio n window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。 发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。 慢开始算法：当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。
- 快重传和快恢复
如果发送方设置的超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。这时，TCP马上把拥塞窗口 cwnd 减小到1，并执行慢开始算法，同时把慢开始门限值ssthresh减半。这是不使用快重传的情况。
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。
6.TCP状态转移，哪些状态
1.CLOSED：起始点，在超时或者连接关闭时候进入此状态。
2.LISTEN：svr端在等待连接过来时候的状态，svr端为此要调用socket， bind,listen函数，就能进入此状态。此称为应用程序被动打开（等待客户端来连接）。
3.SYN_SENT:客户端发起连接，发送SYN给服务器端。如果服务器端不能连接，则直接进入CLOSED状态。
4.SYN_RCVD：跟3对应，服务器端接受客户端的SYN请求，服务器端由LISTEN状态进入SYN_RCVD状态。同时服务器端要回应一个ACK，同时发送一个SYN给客户端；另外一种情况，客户端在发起SYN的同时接收到服务器端得SYN请求，客户端就会由SYN_SENT到SYN_RCVD状态。
5.ESTABLISHED：服务器端和客户端在完成3次握手进入状态，说明已经可以开始传输数据了。
以上是建立连接时服务器端和客户端产生的状态转移说明。相对来说比较简单明了，如果你对三次握手比较熟悉，建立连接时的状态转移还是很容易理解。
接下来服务器端和客户端就进行数据传输。。。。，当然，里面也大有学问，就此打住，稍后再表。
下面，我们来看看连接关闭时候的状态转移说明，关闭需要进行4次双方的交互，还包括要处理一些善后工作（TIME_WAIT状态），注意，这里主动关闭的一方或被动关闭的一方不是指特指服务器端或者客户端，是相对于谁先发起关闭请求来说的：
6.FIN_WAIT_1:主动关闭的一方，由状态5进入此状态。具体的动作时发送FIN给对方。
7.FIN_WAIT_2:主动关闭的一方，接收到对方的FIN ACK，进入此状态。由此不能再接收对方的数据。但是能够向对方发送数据。
8.CLOSE_WAIT：接收到FIN以后，被动关闭的一方进入此状态。具体动作时接收到FIN，同时发送ACK。
9.LAST_ACK：被动关闭的一方，发起关闭请求，由状态8进入此状态。具体动作时发送FIN给对方，同时在接收到ACK时进入CLOSED状态。
10.CLOSING：两边同时发起关闭请求时，会由FIN_WAIT_1进入此状态。具体动作是，接收到FIN请求，同时响应一个ACK。
11.TIME_WAIT：最纠结的状态来了。从状态图上可以看出，有3个状态可以转化成它，我们一一来分析：
a.由FIN_WAIT_2进入此状态：在双方不同时发起FIN的情况下，主动关闭的一方在完成自身发起的关闭请求后，接收到被动关闭一方的FIN后进入的状态。
b.由CLOSING状态进入:双方同时发起关闭，都做了发起FIN的请求，同时接收到了FIN并做了ACK的情况下，由CLOSING状态进入。
c.由FIN_WAIT_1状态进入：同时接受到FIN（对方发起），ACK（本身发起的FIN回应），与b的区别在于本身发起的FIN回应的ACK先于对方的FIN请求到达，而b是FIN先到达。这种情况概率最小。
关闭的4次连接最难理解的状态是TIME_WAIT，存在TIME_WAIT的2个理由：
1.可靠地实现TCP全双工连接的终止。
2.允许老的重复分节在网络中消逝。