1. TCP UDP 区别，分别适用什么场景？
- TCP面向连接（三次握手），通信前需要先建立连接；UDP面向无连接，通信前不需要连接。
- TCP通过序号、重传、流量控制、拥塞控制实现可靠传输；UDP不保障可靠传输，尽最大努力交付。
- TCP面向字节流传输，因此可以被分割并在接收端重组；UDP面向数据报传输。
- TCP支持点对点单播，UDP支持单播，多播和广播
- TCP首部开销大，20字节。UDP首部8字节。
- UDP简单，可应用于多媒体应用，TCP相对复杂，应用于FTP，电子邮件等
2. TCP怎么保证可靠传输
- （1）***、确认应答、超时重传
数据到达接收方，接收方需要发出一个确认应答，表示已经收到该数据段，并且确认号说明了它下一次需要接收的数据***。若发送方迟迟未收到确认应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这时发送发在等待一段时间后进行重传。 - （2）流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。
- （3）拥塞控制：当网络拥塞时，减少数据的发送。
3. TCP 三次握手和四次挥手(详细)，TCP握手以及每一次握手客户端和服务器端处于哪个状态（11种状态）
（1）TCP状态转换图
（2）TCP三次握手
- （1）假定主机A运行的是TCP客户程序，B运行TCP服务器程序，最初两端的进程都处于CLOSE状态。A主动打开，B被动打开。
- （2）B先创建传输控制块TCP，然后处于Listen状态，等待客户请求连接。
- （3）A在打算进行建立连接时，向B发送请求报文含有SYN=1,seq=x。（注意，规定SYN报文段不能携带数据）。这时，客户端进程进入SYN_SENT（同步已发送） 状态。
- （4）B收到连接请求后，如果同意建立，就向A发送确认。传输内容有SYN=1,ACK=1,seq=y,ack=x+1。TCP服务器端进入SYN_RCVD(同步收到)状态
- （5）TCP客户端收到B的确认后，还要向B给出确认。ACK=1,ack=y+1,seq=x+1。（TCP规定ACK报文段可以携带数据，若不携带数据，下一次发送序号seq=x+1）。这时候A进入ESTABLISHED（已建立连接） 状态。
（3）TCP四次挥手
- （1）当前A和B都处于ESTABLISHED状态，当数据传输结束后，通信的双方都可以释放连接。A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A发送 FIN=1,seq=u。此时A进入FIN-WAIT-1(终止等待1) 状态，等待B的确认。（FIN即使不传输数据也消耗一个序号）
- （2）B收到里报文段后即发出确认，内容为：ACK=1,seq=v,ack=u+1。然后B进入到CLOSE-WAIT(关闭等待) 状态。TCP此时应通知服务器端的高层应用进程，因为从A到B这个方向的连接就是放了，此时的TCP连接处于半关闭 状态，即A已经没有数据要发送了，但B若发送数据，A要接受。
- （3）A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2） 状态
- （4）等待B发出的连接释放报文段。若B已经没有要发送的报文了，就通知TCP释放连接。发送内容为：FIN=1,seq=w(可能在瓣关闭状态又发送了一些报文)，ack=u+1。此时B进入了LAST-ACK（最后确认）状态。
- （5）A收到B连接释放报文后必须发出确认，内容为：ACK=1,seq=u+1,ack=w+1。然后A进入到了TIME-WAIT（时间等待） 状态。必须经过2MSL后，A才进入到CLOSE状态。
- （6）B端收到确认报文后立即进入CLOSE状态，
4. TCP中断连接时为什么要有time_wait状态？TIME_WAIT的意义（为什么要等于2MSL）
MSL叫做最长报文段寿命。
- (1) 为了保证A发出的最后一个ACK报文段能够到达B
- (2) 防止“已失效的连接请求报文段”出现在本连接中
5. TCP连接的建立为什么是三次握手而不是两次握手？为什么客户端最后还要发送一次确认呢
如果仅两次连接可能出现一种情况：客户端发送完连接报文（第一次握手）后由于网络不好，延时很久后报文到达服务端，服务端接收到报文后向客户端发起连接（第二次握手）。此时客户端会认定此报文为失效报文，但在两次握手情况下服务端会认为已经建立起了连接，服务端会一直等待客户端发送数据，但因为客户端会认为服务端第二次握手的回复是对失效请求的回复，不会去处理。这就造成了服务端一直等待客户端数据的情况，浪费资源。
6. TCP为什么挥手是四次而不是三次
（1）TCP是全双工的，它允许两个方向的数据传输被独立关闭。当主动发起关闭的一方关闭连接之后，TCP进入半关闭状态，此时主动方可以只关闭输出流。
（2）之所以不是三次而是四次主要是因为被动关闭方将"对主动关闭报文的确认"和"关闭连接"两个操作分两次进行。
（3）对主动关闭报文的确认是为了快速告知主动关闭方，此关闭连接报文已经收到。此时被动方不立即关闭连接是为了将缓冲中剩下的数据从输出流发回主动关闭方（主动方接收到数据后同样要进行确认），因此要把"确认关闭"和"关闭连接"分两次进行。
7. TCP拥塞控制详解，以及算法名字？（极其重要）
cwnd: 拥塞窗口
ssthresh: 慢开始门限
发送方让自己的发送窗口等于拥塞窗口
当cwnd< ssthresh，cwnd以慢开始的方法指数增长；
当cwnd> ssthresh，cwnd以拥塞避免的方法线性增长。
新ssthresh=原来的ssthresh/2
快重传：收到3个同样的确认就立刻重传，不等到超时；
快恢复：cwnd不是从1重新开始，从上一个ssthresh/2+3开始，采用拥塞避免算法
总体：加法增大AI，乘法减小MD
8. 流量控制的介绍，采用滑动窗口会有什么问题（死锁可能，糊涂窗口综合征）？
（1）介绍
流量控制是通过滑动窗口为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。例如将窗口字段设置为 0，则发送方不能发送数据。
（2）问题
- 死锁：B向A发送0窗口报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送rwnd=400报文，但是这个报文在传输过程中丢失了，而现在A一直在等着B发送的非0窗口的报文，B也一直等A发送的数据，这样就会互相等待的死锁局面。
- 糊涂窗口综合征 ：TCP接收方的存储已经满了，而交互进程一次只从缓存区读取一个字节，这样缓存去腾出一个字节空间，给A发送确认，窗口大小为1，接着发来了一个字节的数据。这样一直下去，网络的效率很低。
（3）解决方法
让接收方等待一段时间，使得接受缓存区已有足够的空间容纳一个最长的报文段，或者等待接收缓存已经有了一半的空闲空间。有这两种情况之一，就发送确认报文。
9. 拥塞控制和流量控制的区别，发送窗口的大小取决于流量控制还是拥塞控制？
- 拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。
- 流量控制：指点对点通信量的控制，是端到端中的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收
- 发送窗口的大小=Min[拥塞窗口，接收窗口]，因此是两种控制共同作用。
10. 有没有不是因为拥塞控制而引起的分组丢失的情况？如果有，举例。
（1）IP数据包在数据传输的时候需要分片，但其中一个未能及时到达终点，而终点组装IP数据包已经超时，因而只能丢弃该数据报。
（2）IP数据报已经到达终点，但是终点的缓存没有足够的空间存放此数据
（3）数据报在转发过程中经过一个局域网的网桥，但是网桥在转发该数据报的帧的时候没有足够的差错空间而丢弃。
11. TCP传输数据时，如果有一个确认报文丢失了，也不一定会引起与该确认报文段对应数据的重传。说明理由
尚未重传便收到了对更高序号的确认。