tcp相关问题
1.linux下相关配置文件
内核、网络配置文件
vi /etc/sysctl.conf
/proc/sys/net/XXX
sudo sysctl -p
1.如果syn包超时会发生什么？
超时会重传，重传的时候会采用指数退避，下次的RTO是上次的两倍。
RTO在RFC6298中，定义为1秒。在RFC 1122中，该值为3秒。
- 根据linux下的/proc/sys/net/ipv4/tcp_syn_retries文件确定重传次数。
- 应用程序的socket指定了tcp的TCP_SYNCNT重传次数
- 应用程序主动断开，不再重传
2.为什么是3次握手
S需要确认C受到应答，如果只有两次，会导致S最后一个报文在丢失的情况下，不断重传。而C由于未建立链接，也会不断重传syn报文。但这种情况下，协议并没有定义这种情况S怎么处理，但是可行的方案有，1.归到前面建立的稳定链接上，会导致连接被劫持的问题，很严重。2.断开之前的连接，也是很严重的问题。
双方要建立稳定的连接，才可以协商管理这个链接的生命周期。需要是一个确定的状态。
3.为什么是4次挥手
有一段可能还有消息有发。
4.为什么是2MSL
如果S没有收到报文，会重传自己的FIN，这个时间在所以需要保证2MSL的等待时间，主要是为了保证S收到了ACK
5.如果稳定建链，有一端退出怎么办
net.ipv4.tcp_keepalive_time：发送探测报文之前的链接空闲时间，默认为7200s。 net.ipv4.tcp_keepalive_intvl：两次探测报文发送的时间间隔，默认为75s。 net.ipv4.tcp_keepalive_probes：探测次数。
6.tcp的滑动窗口
- 报文中的窗口字段有16位，也就是2的16次方，65535字节。
再乘以窗口缩放因子有14位，也就是2的14次方
-
这个字段在syn报文中指定，由于告诉对端自己的接收窗口大小
-
发送窗口只有在对端收到应答之后才滑动，通过本端的收到的ack确认对端收到应答。
-
如果自己的窗口满了，发送一个0窗口报文，恢复了再发一个恢复的报文，实现流量控制。
7.tcp拥堵控制
包括 慢启动（）、拥塞避免、快速重传、快速恢复 这4方面
发送窗口
发送方窗口的上限值 = Min [ rwnd, cwnd ]
当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值。
当cwnd < rwnd 时，则是网络的拥塞限制发送方窗口的最大值。
8.可靠传输
- 停止等待协议:接受到应答才发送下一个报文。
超时时间应设置得比平均往返时间长一点、当不能太多，为了效率。
连续ARQ和停止等待协议
SACK，给出一个左边界和右边界，告知发送端还有哪些报文没有收到
- 确认丢失和确认迟到:C没有收到应答就重传，S收到重复应答丢弃并回复(如果不回复，在自己的应答丢失的场景下有问题)，C如果收到两个应答就丢弃后面那个。
