TCP面试相关总结

TCP三次握手过程
　1）主机A发送标志syn＝1,随机产生seq =1234567的数据包到服务器，主机B由syn=1知道，A要求建立连接； 此时状态A为SYN_SENT，B为LISTEN
　2）主机B收到请求后要确认连接信息，向A发送ack =(主机A的seq+1),标志syn=1,ack=1,随机产生seq=7654321的包，　此时状态A为ESTABLISHED，B为SYN_RCVD　
　3）主机A收到后检查ack 是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack =(主机B的seq+1),标志ack=1，主机B收到后确认seq值与ack=1则连接建立成功。 此时A、B状态都变为ESTABLISHED 　

2、TCP四次挥手过程

　　断开连接过程与建立连接类似
1）主机A发送位码为FIN＝1，用来关闭客户A到服务器B的数据传送。此时A的状态为FIN_WAIT_1
2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。此时A为FIN_WAIT_2，B为CLOSE_WAIT
3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A。此时A为TIME_WAIT，B为LAST_ACK
4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。此时A、B都关闭了，状态变为CLOSED。
当（2）、（3）步中的ACK和FIN在一个包中发送时，A的状态会直接从FIN_WAIT_1变为TIME_WAIT

3、为什么建立连接需要三次握手，而断开连接需要四次握手
　　因为每个方向都需要一个FIN和ACK，当一端发送了FIN包之后，处于半关闭状态，此时仍然可以接收数据包。
　　但是在断开连接时，如果一端收到FIN包，但此时仍有数据未发送完，此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后，再向对端发送FIN，断开这个方向的连接。
　　因此很多时候FIN和ACK需要在两个数据包中发送，因此需要四次握手

4、TIME_WAIT状态持续时间及原因

　　持续时间未2MSL，一个数据包在网络中的最长生存时间为MSL。
　　假设最后客户端回复的ACK丢失，服务器端会在超时时间到来时，重传最后一个FIN包

5、超时重传和快速重传 　　

超时重传：当超时时间到达时，发送方还未收到对端的ACK确认，就重传该数据包
快速重传：当后面的序号先到达，如接收方接收到了1、 3、 4，而2没有收到，就会立即向发送方重复发送三次ACK=2的确认请求重传。如果发送方连续收到3个相同序号的ACK，就重传该数据包。而不用等待超时

7、TCP选项有哪些

　　TCP首部选项字段多达40B，一些常用的字段有：
　　1）选项结束字段（EOP，0x00），占1B，一个报文段仅用一次。放在末尾用于填充，用途是说明：首部已经没有更多的消息，应用数据在下一个32位字开始处
　　2）无操作字段（NOP, 0x01），占1B，也用于填充，放在选项的开头
　　3）MSS（最大报文段长度），格式如下：种类（1B，值为2），长度（1B，值为4），数值（2B）
　　用于在连接开始时确定MSS的大小，如果没有确定，就用默认的（一般实现是536B）
　　4）窗口扩大因子，格式如下：种类（1B，值为3），长度（1B，值为3),数值（1B）
　　新窗口值 = 首部窗口值 * 2的（扩大因子）次方
　　当通信双方认为首部的窗口值还不够大的时候，在连接开始时用这个来定义更大的窗口。仅在连接开始时有效。一经定义，通信过程中无法更改。
　　5）时间戳（应用测试RTT和防止序号绕回）
　　6）允许SACK和SACK选项

10、三次握手过程中有哪些不安全性

　　1）伪装的IP向服务器发送一个SYN请求建立连接，然后服务器向该IP回复SYN和ACK，但是找不到该IP对应的主机，当超时时服务器收不到ACK会重复发送。当大量的攻击者请求建立连接时，服务器就会存在大量未完成三次握手的连接，服务器主机backlog被耗尽而不能响应其它连接。即SYN泛洪攻击
　　防范措施：
　　1、降低SYN timeout时间，使得主机尽快释放半连接的占用
　　2、采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文
　　3、在网关处设置过滤，拒绝将一个源IP地址不属于其来源子网的包进行更远的路由
　　
11、TCP和UDP的区别

TCP是有连接的，两台主机在进行数据交互之前必须先通过三次握手建立连接；而UDP是无连接的，没有建立连接这个过程
TCP是可靠的传输，TCP协议通过确认和重传机制来保证数据传输的可靠性；而UDP是不可靠的传输
TCP还提供了拥塞控制、滑动窗口等机制来保证传输的质量，而UDP都没有
TCP是基于字节流的，将数据看做无结构的字节流进行传输，当应用程序交给TCP的数据长度太长，超过MSS时，TCP就会对数据进行分段，因此TCP的数据是无边界的；而UDP是面向报文的，无论应用程序交给UDP层多长的报文，UDP都不会对数据报进行任何拆分等处理，因此UDP保留了应用层数据的边界

12、有哪些应用层协议是基于TCP的，哪些是基于UDP的

TCP： FTP、HTTP、Telnet、SMTP、POP3、HTTPS
UDP：DNS、SNMP、NFS

TCP可靠传输的实现：
1.以字节为单位的滑动窗口
发送窗口的位置有窗口前沿和后沿的位置共同决定。发送窗口后沿的变化情况有两种，即不动（没有收到新的确认）和前移（收到了新的确认）。
描述一个发送窗口的状态需要三个指针：P1，P2，P3。
小于P1的是已发送并已收到确认的部分，而大于P3的是不允许发送的部分。
P3-P1=A的发送窗口
P2-P1=已发送但尚未收到确认的字节数
P3-P2=允许发送但当前尚未发送的字节数（称为可用窗口）

假如发送方发送31，32，33，接受方收到序号为32，33的数据，序号31的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意，B只能对按序到达的数据中的最高序号给出确认，因此B发送的确认报文段的确认号仍然是31，而不能是32或者33。
对于32，33这种未按序到达的数据会暂存在接收窗口中。

还有一种可能性，就是发送窗口内所有的数据都已正确到达B，B也早已做出确认，但是不幸的是，所有的这些确认都滞留在网络中。为了保证可靠传输，A只能认为B还没有收到这些数据。于是，A在经过一段时间后（由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。如果A收到确认号落在发送窗口中，那么A就可以使发送窗口继续向前滑动、

强调一下三点：
1.虽然A的发送窗口是根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口的数值。
2.对于不按序到达的数据如何处理。TCP对于不按序到达的数据是先存放在接受窗口中，等待字节流中所缺少的字节收到后，再按序交付上层的应用进程。
3.TCP要求接收方必须有累积确认的功能。

2.超时重传
TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。

3.选择确认SACK
只设法传输缺少的数据而不重传已经正确到达接收方的数据。
如果收到的字节序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。

TCP流量控制
让发送方的发送速率不要太快，要让接收方来得及接收，滑动窗口是接收数据端使用的窗口大小。

发送方的发送窗口不能超过接收方给出的接收窗口的数值。