网络协议简单总结

http协议中get和post的区别

• GET在浏览器回退时是无害的，而POST会再次提交请求。
• GET产生的URL地址可以被Bookmark，而POST不可以。
• GET请求会被浏览器主动cache，而POST不会，除非手动设置。
• GET请求只能进行url编码，而POST支持多种编码方式。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
• GET请求在URL中传送的参数是有长度限制的，而POST么有。
• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。但从http协议的角度来看其实都不安全，因为参数还是明文传输的，除非使用https加密传输才安全。
• GET参数通过URL传递，POST放在Request body中。

（本标准答案参考自w3schools）

 

无论是get请求还是post请求，本质上都是tcp连接。但对于get请求方式，浏览器会把http header和data一起发送，服务器响应200，返回数据。

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。（并不是所有浏览器post请求都会发送两次，firefox就不会）

 

参考：

https://mp.weixin.qq.com/s?__biz=MzI3NzIzMzg3Mw==&mid=100000054&idx=1&sn=71f6c214f3833d9ca20b9f7dcd9d33e4#rd

 

 

---

 

tcp/ip协议

 

tcp头部格式

这张图把TCP协议头部格式的每部分都描述得比较清楚：

1. Source Port与Destination Port表示源端口与目标端口，各占据2个字节
2. Sequence Number表示顺序号，占4个字节，每一个字节都有一个序号，连接建立时发送方将初始序号填写到第一个发送的TCP段序号中
3. Acknowledgment Number表示应答号，占4个字节，是期望收到对方下次发送的数据的第一个字节的序号，也就是期望收到的下一个报文段的首部中的序号
4. Offset表示数据偏移量，占4位，表示数据开始的地方离TCP段的起始处有多远，实际上就是TCP段首部的长度
5. Reserved表示保留位，占4位，全为0，为了将来定义新的用途保留
6. C表示CWR，占1位，拥塞窗口减少标识，发送方设置，用于表明它收到了ECE标识的TCP包，发送端通过降低发送窗口的大小来降低速率
7. E表示ECN，占1位，用于TCP3次握手时表示一个TCP端是具备ECN功能的
8. U表示URG，占1位，该标志位表示紧急标识有效
9. A表示ACK，占1位，表示Acknowledgment Number字段有效，这是一个确认的TCP包，0表示不是确认包
10. P表示PSH，占1位，该标志位设置时一般表示发送端缓存中已经没有待发送的数据，接收端不将该数据进行队列处理
11. R表示RST，占1位，用于复位相应的TCP链接
12. S表示SYN，占1位，该标志仅在三次握手建立TCP连接时有效
13. F表示FIN，占1位，带有该标志位的数据包用来结束一个TCP会话，但对应端口仍处于开放状态，准备接收后续数据
14. Window表示窗口，占2个字节，表示报文段发送方期望收到的字节数，换句话说用于表示接收端还有多少空间剩余，用于控制TCP流量
15. Checksum表示校验和，占2个字节，发送端基于数据内容计算一个数值，接收端要与发送端数值结果完全一样，才能证明数据的有效性，接收端校验失败会直接丢掉这个数据包
16. Urgent Pointer表示紧急指针，占2个字节，指向后面优先数据的字节，只有在URG标识设置了才有效
17. TCP Options表示TCP选项，长度不定，但必须是32bits的整数倍，常见的选项包括MSS、SACK、Timestamp等

从图上我们可以看到，TCP头部的固定大小为20个字节，不过由于有可选字段，实际上TCP头部的大小有可能超过20字节。

 

名词解释：

Sequence Number是包的序号，用来解决网络包乱序（reordering）问题。

Acknowledgement Number就是ACK——用于确认收到，用来解决不丢包的问题。

Window又叫Advertised-Window，也就是著名的滑动窗口（Sliding Window），用于解决流控的。

TCP Flag ，也就是包的类型，主要是用于操控TCP的状态机的。

MSS–最大传输包

MSL--数据包最大传输时长(报文最大生存时间,他是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃)

SACK_PERM–是否支持Selective ack(用户优化重传效率）

WS–窗口计算指数（有点复杂的话先不用管）

 

SYN超时

关于建连接时SYN超时。试想一下，如果server端接到了clien发的SYN后回了SYN-ACK后client掉线了，server端没有收到client回来的ACK，那么，这个连接处于一个中间状态，即没成功，也没失败。于是，server端如果在一定时间内没有收到的TCP会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻售，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才会把断开这个连接。

 

重传机制

TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。

注意，接收端给发送端的Ack确认只会确认最后一个连续的包，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4（注意此时3没收到），此时的TCP会怎么办？我们要知道，因为正如前面所说的，SeqNum和Ack是以字节数为单位，所以ack的时候，不能跳着确认，只能确认最大的连续收到的包，不然，发送端就以为之前的都收到了。

 

超时重传机制

一种是不回ack，死等3，当发送方发现收不到3的ack超时后，会重传3。一旦接收方收到3后，会ack 回 4——意味着3和4都收到了。

但是，这种方式会有比较严重的问题，那就是因为要死等3，所以会导致4和5即便已经收到了，而发送方也完全不知道发生了什么事，因为没有收到Ack，所以，发送方可能会悲观地认为也丢了，所以有可能也会导致4和5的重传。

对此有两种选择：

一种是仅重传timeout的包。也就是第3份数据。

另一种是重传timeout后所有的数据，也就是第3，4，5这三份数据。

这两种方式有好也有不好。第一种会节省带宽，但是慢，第二种会快一点，但是会浪费带宽，也可能会有无用功。但总体来说都不好。因为都在等timeout，timeout可能会很长（在下篇会说TCP是怎么动态地计算出timeout的）

 

快速重传机制

于是，TCP引入了一种叫Fast Retransmit 的算法，不以时间驱动，而以数据驱动重传。也就是说，如果，包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传。Fast Retransmit的好处是不用等timeout了再重传。

 

比如：如果发送方发出了1，2，3，4，5份数据，第一份先到送了，于是就ack回2，结果2因为某些原因没收到，3到达了，于是还是ack回2，后面的4和5都到了，但是还是ack回2，因为2还是没有收到，于是发送端收到了三个ack=2的确认，知道了2还没有到，于是就马上重转2。然后，接收端收到了2，此时因为3，4，5都收到了，于是ack回6。示意图如下：

Fast Retransmit只解决了一个问题，就是timeout的问题，它依然面临一个艰难的选择，就是，是重传之前的一个还是重传所有的问题。对于上面的示例来说，是重传#2呢还是重传#2，#3，#4，#5呢？因为发送端并不清楚这连续的3个ack(2)是谁传回来的？也许发送端发了20份数据，是#6，#10，#20传来的呢。这样，发送端很有可能要重传从2到20的这堆数据（这就是某些TCP的实际的实现）。可见，这是一把双刃剑。

 

sack方法

另外一种更好的方式叫：Selective Acknowledgment (SACK)（参看RFC 2018），这种方式需要在TCP头里加一个SACK的东西，ACK还是Fast Retransmit的ACK，SACK则是汇报收到的数据碎版。参看下图：

这样，在发送端就可以根据回传的SACK来知道哪些数据到了，哪些没有到。于是就优化了Fast Retransmit的算法。当然，这个协议需要两边都支持。在 Linux下，可以通过tcp_sack参数打开这个功能（Linux 2.4后默认打开）。

tcp的慢启动和ack

服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。

最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。

TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。

Linux 内核里面设定了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。

默认情况下，接收方每收到两个 TCP 数据包，就要发送一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。

ACK 携带两个信息。

• 期待要收到下一个数据包的编号
• 接收方的接收窗口的剩余容量

发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。

（图片说明：每个 ACK 都带有下一个数据包的编号，以及接收窗口的剩余容量。双方都会发送 ACK。）

注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。

（图片说明：上图一共4次通信。第一次通信，A 主机发给B 主机的数据包编号是1，长度是100字节，因此第二次通信 B 主机的 ACK 编号是 1 + 100 = 101，第三次通信 A 主机的数据包编号也是 101。同理，第二次通信 B 主机发给 A 主机的数据包编号是1，长度是200字节，因此第三次通信 A 主机的 ACK 是201，第四次通信 B 主机的数据包编号也是201。）

即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。

 

为什么主动关闭的一方不直接进入CLOSED状态，而是进入TIME_WAIT状态

 

为什么主动关闭的一方不直接进入CLOSED状态，而是进入TIME_WAIT状态，并且停留两倍的MSL时长呢？这是因为TCP是建立在不可靠网络上的可靠的协议。例子：主动关闭的一方收到被动关闭的一方发出的FIN包后，回应ACK包，同时进入TIME_WAIT状态，但是因为网络原因，主动关闭的一方发送的这个ACK包很可能延迟，从而触发被动连接一方重传FIN包。极端情况下，这一去一回，就是两倍的MSL时长。如果主动关闭的一方跳过TIME_WAIT直接进入CLOSED，或者在TIME_WAIT停留的时长不足两倍的MSL，那么当被动关闭的一方早先发出的延迟包到达后，就可能出现类似下面的问题：

• 旧的TCP连接已经不存在了，系统此时只能返回RST包
• 新的TCP连接被建立起来了，延迟包可能干扰新的连接

 

不管是哪种情况都会让TCP不再可靠，所以TIME_WAIT状态有存在的必要性。

服务器端尽量不主动关闭tcp连接，不然会积压很多time_wait的连接，尽量让客户端主动关闭tcp连接，这样客户端会进入time_wait状态。

 

TCP协议头详解以及三次握手

所谓"已失效的连接请求报文段"是这样产生的。正常来说，客户端发出连接请求，但因为连接请求报文丢失而未收到确认。于是客户端再次发出一次连接请求，后来收到了确认，建立了连接。数据传输完毕后，释放了连接，客户端一共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，没有"已失效的连接请求报文段"。

现在假定一种异常情况，即客户端发出的第一个连接请求报文段并没有丢失，只是在某些网络节点长时间滞留了，以至于延误到连接释放以后的某个时间点才到达服务端。本来这个连接请求已经失效了，但是服务端收到此失效的连接请求报文段后，就误认为这是客户端又发出了一次新的连接请求。于是服务端又向客户端发出请求报文段，同意建立连接。假定不采用三次握手，那么只要服务端发出确认，连接就建立了。

由于现在客户端并没有发出连接建立的请求，因此不会理会服务端的确认，也不会向服务端发送数据，但是服务端却以为新的传输连接已经建立了，并一直等待客户端发来数据，这样服务端的许多资源就这样白白浪费了。

采用三次握手的办法可以防止上述现象的发生。比如在上述的场景下，客户端不向服务端的发出确认请求，服务端由于收不到确认，就知道客户端并没有要求建立连接。

 

为什么TCP连接的建立只需要三次握手而TCP连接的释放需要四次握手呢

因为服务端在LISTEN状态下，收到建立请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而连接关闭时，当收到对方的FIN报文时，仅仅表示对方没有需要发送的数据了，但是还能接收数据，己方未必数据已经全部发送给对方了，所以己方可以立即关闭，也可以将应该发送的数据全部发送完毕后再发送FIN报文给客户端来表示同意现在关闭连接。从这个角度而言，服务端的ACK和FIN一般都会分开发送。

 

TCP网络关闭的状态变换时序图

https://app.yinxiang.com/Home.action#n=3c16af04-3040-409c-916f-d413f1e2b026&s=s43&b=9f310328-68bc-4655-9dec-36d30ed8c15e&ses=4&sh=1&sds=5&

 

tcp协议http协议中的keep-Alive

tcp的keep-Alive

这时候TCP协议提出一个办法，当客户端端等待超过一定时间后自动给服务端发送一个空的报文， 如果对方回复了这个报文证明连接还存活着，如果对方没有报文返回且进行了多次尝试都是一样， 那么就认为连接已经丢失，客户端就没必要继续保持连接了。 如果没有这种机制就会有很多空闲的连接占用着系统资源。

https://app.yinxiang.com/Home.action#n=74534e39-a5bb-4b07-8646-8cde6f08ddf6&s=s43&ses=4&sh=2&sds=5&

http的keep-Alive

在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。

使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。

但是，keep-alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。

当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。

 

参考：

https://coolshell.cn/articles/11564.html

http://www.cnblogs.com/xrq730/p/6910719.html

http://www.ruanyifeng.com/blog/2017/06/tcp-protocol.html