计算机网络总结
https协议是这样的
https协议的请求的请求行，以及请求头部都是基于文本协议的，所以实现http协议的时候，最好用
getline类似的函数去读，tcp层按照编号将数据组装好，https协议将数据读到缓冲区后，一行一行的读取，并逐渐解析，因为post请求是有基于二进制的文件的数据段，所以在https的实现中，在请求头部中有数据段的大小，并且请求头部和数据部分用两个换行符隔开，意味着，请求头部结束（请求头部可以有多行），数据段开始了，，，这些保证了http协议不会出问题。
关于tcp协议：
tcp报文格式
1、***：***是数据段中第一个字节的序号，注意当，SYN=1和FIN=1，数据段为空，连接请求会占用一个***。接收端，根据***将接收到的数据进行排列。
2、应答号：当标志位ACK=1的时候，应答号ack才有用，所以当发送端发送SYN=1的时候此时ACK!=1，所以会忽略它，这个应答号，是根据接收到的数据包中的***，以及数据长度所确定的，比如接收到的数据包seq=5并且数据长度=3（数据长度在tcp报文头中没有对应的位，但是在ip层有一个数据报总长度的对应位，占为8个字节所以Ipv4的数据包最大长度为65535长度，减去iP层首部20字节，tcp首部20字节，那么可以携带的理论上是65535-40,但是受物理层硬件方面的的限制，以太网的MTU=1500，为了不在网络层对数据进行分片，从而减少出错以及提高传输效率，那么实际上就是数据长度为1460。ipv4的实现中，要求最小重组区为576,也就是只要数据长度<=576那么就不会被分段。mss为实际的数据长度，也就是最大的数据长度。http://blog.csdn.net/ysu108/article/details/7764461
这个总结的很好），那么确定号就是8（也就是期待下次发送端发送的数据），当然ack=8的前提是5之前所有的数据包都接收完毕
tcp可靠传输的机制：超时重传，滑动窗口，流量控制，拥塞处理
滑动窗口：tcp有缓冲区，分别为接收缓冲和发送缓冲，窗口是缓冲的一部分。发送缓冲区中的内容分为四个部分：已经发送并且确定的 发送出去没有确定的 发送出去确定的，还没有发送的 其中上述中间的两个部分属于滑动窗口内，接收缓冲区中的内容相应有四个部分，一个是接收到的并且被应用层读取了的，一个是接收到的还没有被读取的，一个是窗口剩余可以继续接收的，一个是在窗口外面的不能够被接收的数据（缓冲区大小和窗口大小并不是相等的，缓冲区是容纳数据的，而窗口大小并不是等于缓冲区大小，但是实际上应该是这种情况，接收缓冲区，应该是分为三个部分，没有最后一部分不能被接收的，窗口大小为后两者，而发送窗口大小是根据对端接收窗口调整的，所以可能是四个部分），滑动窗口的意义：控制流量，将未收到确定的数据和收到确定的数据分开
流量控制：当对方接收缓冲中剩余空间不足，来不及接收过多的数据包，所以需要进行流量控制
1、传输效率（何时传输）：
A：当窗口中的数据可以组成一个mss的时候就发出去
B：不足MSS的时候，当计时器期限到了也要往出发
C：TCP支持推送，推送的这个东西可以不按照编号（即使在窗口外面）提前往出发，接收方也要先处理它
2、nagle算法：nagle算法就是基于上述传输效率的一种实现
伪代码：
if there is new data to send #有数据要发送
# 发送窗口缓冲区和队列数据 >=mss，队列数据（available data）为原有的队列数据加上新到来的数据
# 也就是说缓冲区数据超过mss大小，nagle算法尽可能发送足够大的数据包
if the window size >= MSS and available data is >= MSS
send complete MSS segment now # 立即发送
else
if there is unconfirmed data still in the pipe # 前一次发送的包没有收到ack
# 将该包数据放入队列中，直到收到一个ack再发送缓冲区数据
enqueue data in the buffer until an acknowledge is received
else
send data immediately # 立即发送
end if
end if
end if
还有一个算法叫做cork算法，这个算法是尽量让小包停留组合成一个MSS的包在发出去
关于更多的https://baike.baidu.com/item/Nagle%E7%AE%97%E6%B3%95/5645172?fr=aladdin
3、糊涂窗口
当发送端产生数据很慢，或者接受端处理数据很慢，使得数据段的大小很小而tcp+ip首部就有20字节，导致传送效率很低
发送端可以使用nagle算法
接收端有两种方法处理：
向发送端返回的报文中窗口大小为0，这样发送端就不会在往出发数据了，每隔一定的时间发送端向接收端询问是否窗口有变化
另一种是发送端延迟确定，发送端没有得到确定的时候就不能确定窗口大小，就不继续往出发了，当然，延迟的时间肯定要小于超时重传的时间
详细参考这里https://baike.baidu.com/item/%E7%B3%8A%E6%B6%82%E7%AA%97%E5%8F%A3%E7%BB%BC%E5%90%88%E5%BE%81/6167377?fr=aladdin