- GET 请求获取Request-URI所标识的资源
- POST 在Request-URI所标识的资源后附加新的数据
- PUT 请求服务器存储一个资源，并用Request-URI作为其标识
- DELETE 请求服务器删除Request-URI所标识的资源
- HEAD 请求获取由Request-URI所标识的资源的响应消息报头
- OPTIONS 请求查询服务器的性能，或者查询与资源相关的请求和需求
- TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
- CONNECT 保留将来使用
client->server: SYN=1;seq=x
server->client:SYN=1;ACK=x+1;seq=y
client->server:ACK=y+1;
client->server:FIN=1; seq=x
server->client:ACK=x+1;
server->client:FIN=1;seq=y
client->server:ACK=y+1
确认包的Ack = 待确认数据包的Seq + 待确认数据包的数据长度（Len）
既然总结了TCP的三次握手，那为什么非要三次呢？怎么觉得两次就可以完成了。那TCP为什么非要进行三次连接呢？在谢希仁的《计算机网络》中是这样说的：
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
在书中同时举了一个例子，如下：
“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
这就很明白了，防止了服务器端的一直等待而浪费资源。
那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
参考：
http://www.jellythink.com/archives/705
影响超时重传机制协议效率的一个关键参数是重传超时时间（RTO，Retransmission TimeOut）
在《TCP/IP详解》中，实际测量的重传机制如图3所示，重传的时间间隔，取整后分别为1、3、6、12、24、48和多个64秒。这个倍乘的关系被称为“指数退避”。
OPPO手机TCP超时重传的间隔，依次为[ 0.25s，0.5s，1s，2s，4s，8s，16s，32s，64s，64s，64s …]
SamSung 中 TCP 超时重传的间隔依次为[0.42s, 0.9s, 1.8s, 3.7s, 7.5s, 15s, 30s, 60s, 120s, 120s …]
经过多次实际测试我们可以看出虽然由于不同厂商的 Android 系统实现，RTO 的值可能会有不同的设定，但都基本符合“指数退避”原则。
通过上述的调研与实验，可以发现在 TCP/IP 中，协议栈已经帮助我们进行了超时与重传的控制。并且在 Android、iOS 的移动操作系统中进行了优化，使用了更为积极的策略，以适应移动网络不稳定的特征。
那么，应用层的超时重传机制应该提供怎样的服务呢？
首先，我们来看一下应用层重传的做法。在应用层中，重传的做法是：断掉当前连接，重新建立连接并发送请求。这种重传方式能带来怎样的作用呢？回顾 TCP 层的超时重传机制可以发现，当发生超时重传时，重传的间隔以“指数退避”的规律急剧上升。在 Android 系统中，直到16分钟，TCP 才确认失败；在 iOS 系统中，直到1分半到3分半之间，TCP 才确认失败。这些数值在大部分应用中都是不为“用户体验”所接受的。
虽然 TCP/IP 协议栈中的链路层、传输层都已经提供了超时重传，保障了传输的可靠性。但应用层有着不同的可靠性需求，从而需要额外的应用层超时重传机制来保障应用的高性能、高可用。应用层超时重传的设计目标，笔者从自身经验出发，总结为：
- 在用户体验的接受范围内，尽可能地提高成功率；
- 保障弱网络下的可用性；
- 具有网络敏感性，快速地发现新的链路。
数据及结论参考：