TCP精辟问题：
TCP是可靠的，面向连接，每走一步都需要确认，缺点就是耗费太大的资源，但是也就是贵的东西才耗费资源，如果处理重要的文件，还是需要选择TCP，毕竟他是可靠的
TCP
- 面向连接、字节流和可靠传输
- 有序的
- 流控：管理发送数据的速率，不要超过设备的承载能力
三次握手
为什么建立三次握手？
- 维持一个连接状态
- 通信双方互相通知对方自己初始化的sequence number(SYN)，保证序列，不乱序
为什么需要四次释放？
- 因为TCP是全双工的，A和B有连接，B和A也有连接，发送方和接受方都需要ACK和FIN，所以需要四次释放
TCP连接状态
- CLOSED初始状态
- FIN_WAIT_1 双方建立好连接后，一方请求终止，则进入这个状态
- FIN_WAIT_2 对方回应ACK后，进入。 实际上是等待对方发送FIN
- TIME_WAIT 收到对方的FIN报文，发送ACK报文，等待2MSL后回到初始状态
- CLOSING 表示双方都在关闭socket连接，互发FIN报文
为什么TIME_WAIT后要等待2MSL?
- 防止最后一次握手的数据报没有传送到对方那里而准备的，是为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，==B就无法按照正常的步骤进入CLOSED状态==
- TCP端口不能被同时打开多次，当一个TCP连接处于timed_wait状态时，我们将无法立即使用占用的端口建立新连接。那么如果不存在这个状态，应用程序会立即建立一个和刚才一样的连接，可以称之为原来连接的化身，这时可能接收到原来连接上的数据，但是这是不应该出现的问题。那么TCP报文段最大的生存时间是MSL，那么坚持2MSL就可以保证两个传输方向上尚未接收到的和迟到的TCP报文段都消失,就能保证新的连接安全的建立，不受到原连接上应用程序的数据。
超时重传
- 保证数据的可靠传输，设定计时器，一旦重传时间到了，没有确认，则重传。
- RTO超时重传时间，利用自适应性算法 RTT连接往返时间
滑动窗口：http://blog.csdn.net/zhouyongku/article/details/53508476
- 同样保证可靠性传输，其实也是建立在”确认重传”的基础上，发送窗口只有收到ACK，才会移动发送窗口的左边界。而接受窗口只有窗口内前面所有的段都确认的情况下才会移动左边界，如果存在未接受的情况，窗口不会移动，并不对后续字节进行确认。
- 接受端根据自己的状况通告发送端的窗口大小,提供流控特性，并且我们提供了对窗口的动态调整
- 双方各维护一个”发送窗口”和一个”接受窗口”
- 也是一种流量控制方法
拥塞控制
- 防止过多的数据注入网络中，就给交通一样，防止堵塞，使得网路中的路由和链路不至于过载。
慢开始
- 拥塞窗口是字节形式的
- 发送进行试探，从小至大进行发送，防止一次性过多注入网络。
- 为防止拥塞窗口增长过大引起网络拥塞,需要设置一个慢开始阈值，达到阈值进行拥塞避免算法
拥塞避免
- TCP连接初始化，拥塞窗口设置为1，进行慢开始，拥塞窗口按指数规律增长，达到阈值进行拥塞避免按线性增长，发送拥塞后，阈值变为之前的一半，拥塞窗口设置为1，然后乱换着进行慢开始和拥塞避免。
慢开始与拥塞控制存在问题？以及改进方法？
快速重传与快速恢复
- 要求接受方收到一个失序的报文段后就立即发出重复确认，而不必等待发送数据时才捎带确认，使得方法方可以及时得知道自己发送的报文段没有达到对方。
- 一般只要收到3个重复确认就重传，不用等待超时定时器
- 快速恢复
问题来了
摘自于知乎https://www.zhihu.com/question/28943943/answer/155660761
A进程通过TCP向另一台机器上的B进程发送了一个字符串“hello”，TCP返回对方成功接收的确认信息，请问，现在进程A是否可以肯定地说进程B收到了它发送的字符串？
答案：不能！举反例，进程B所在机器的TCP收到进程A发送的“hello”信息后，告诉进程A发送成功，但有可能没有立即将数据交给进程B，而是放在自己的缓冲区中，等待进程B读取，如果机器此时突然掉电，缓冲区中的信息将丢失，进程B将不可能收到“hello”字符串。
有什么办法来尽量避免上述情况的发生呢？ 使对端及时确认
答案：将TCP报文段首部中的PSH标志置1，这样会让B端的TCP协议收到数据后尽快交给进程B，能不缓存尽量不要缓存。
我们知道通常TCP连接的建立需要3次握手，关闭需要4次握手，为什么关闭会多一次呢？
答案：简单说，就是TCP允许半关闭状态的存在。当进程A向进程B发送FIN，B也向A发送确认后。此时此刻的状态就是半关闭状态，A发送的FIN就是告诉B：“我要发送的数据都发送完了”但B没有发送FIN给A，有可能代表B还有没发送完的数据，如果B也发送完数据了，B就发送FIN给进程A，进程A确认B发送的FIN，这时，双方都已经发送完了数据，连接就断开了，TCP回收相关资源。
假如服务器突然掉电重启，但客户端并不知情，请问此时二者之间的TCP连接处于什么状态？
答案：处于半打开状态。就是客户端还觉得连接是正常的，服务器这边已经没有连接的任何信息了。
那么，假如此时客户端通过这个连接向服务器请求数据，服务器会怎么应对呢？
答案：服务器收到客户端的请求会进行一次ARP查询，获得客户端MAC地址，然而由于已经丢失了所有连接信息，此时的服务器是一脸懵逼（就像喝了孟婆汤！），于是乎，它会发一个RST给客户端，表示：“哥们，我不认识你，想跟我说话请先发送SYN！”
假如客户端按照服务器的要求重新建立连接，却搞错了服务器的端口号，会发生什么情况呢> 答案：有两种可能，一种是服务器端的TCP收到客户端请求，查看本机上是否有进程在监听相应的端口，如果有，就把请求交给这个进程，一般而言，这个进程不会接受这个连接的，于是它会发一个RST给客户端。还有一种可能是TCP没有找到哪个进程在监听相应的端口，于是TCP就会直接发一个RST给客户端，一般而言都会是这种情况。
看是否存在进程监听错误的端口，如果有返回RST,进行复位，没有直接返回RST
TCP接收到发送给这个端口的报文段，怎么决定发给哪个进程呢？
答案：首先，所有的SYN报文段都会发送给服务器进程A，其他的报文段依据（sourceIP:port,targetIP:port）这个四元组来决定发送给进程B还是进程C。
假如上面的服务器进程A收到一个连接请求，正在为这个请求创建处理进程的时候，又有新的连接请求进来了，TCP会怎么处理呢？ （进入队列）
答案：一般情况下，服务器进程A会给TCP一个指示，让TCP维护一个适当长度的连接队列，TCP与新连接请求完成三次握手后，就会把这个连接放入连接队列中，服务器进程A会在合适的时候来从这个队列中取连接。
另外这个队列不会对并发产生影响，毕竟是一个进程
MSS和MTU各是什么，二者是什么关系？
MSS（数据字节长度）是TCP最大报文段长度，就是TCP发送数据需要对数据分段时，最大的段的字节数。MTU是最大传输单元，通常由网卡的硬件特性规定，表示通过该网卡传输的数据单元最大的字节数。MSS要受同一台机器上的MTU限制。比如MTU为1500字节，那么MSS就只能是1460字节，这是因为1460字节的数据在通过网卡向外传输时，会加上20字节的ip头和20字节的tcp头。
假设A正常断开与B的TCP连接，当收到B的FIN时，A发送ACK给B，是否就算完成了4次握手，连接已经成功断开？ time_wait
答案：不是，A的TCP会启动一个定时器，等待2MSL的时间，这主要是为了防止A的ACK没有成功传到B，让B以为自己的FIN没有送到A处，反复重传FIN的问题。2MSL的时间到时，如果A没有再次收到B的FIN，说明B成功收到A的ACK，A就可以安全地断开这个连接，若期间再次收到B的FIN，则A会重传ACK。
但是这并不能保证可靠的终止连接，只是表示我已经干完自己的事，仁至义尽了，
TCP中，connect连接成功的标准是？
首先，connect代表TCP的连接过程，即是3次握手的过程，成功的代表也就是客户端发出ACK后，客户端认为三次握手建立完成，状态变为Established，阻塞的connect调用成功返回，如果这个ack丢失， server在定时器溢出后，会重发syn+ack，
IP可以寻址到唯一的主机，为什么还需要mac地址呢?
IP地址本质上是终点地址，它在跳过路由器（hop）的时候不会改变，而MAC地址则是下一跳的地址，每跳过一次路由器都会改变。这就是为什么还要用MAC地址的原因之一，它起到了记录下一跳的信息的作用,记录路由