TCP/IP协议
TCP/IP 是一个协议族，也是按照层次划分。共四层：应用层，传输层，互连网络层，网络接口层。
OSI网络协议模型，是一个参考模型，而TCP/IP协议是事实上的标准。TCP/IP协议参考了OSI 模型，但是并没有严格按照OSI规定的七层去划分标准，而只划分了四层，这样会更简单点，更实用。
TCP/IP协议和OSI模型也并不冲突，TCP/IP协议中的应用层协议，就对应于OSI中的应用层，表示层，会话层。
TCP/IP分层：
我们日常开发中涉及到的网络请求比如http请求和socket都是应用层的，基于tcp协议的。虽然我们没有必要去探究整个协议细节问题，但传输层tcp和udp的一些知识还是需要深入理解的。
http协议
Http协议是建立在TCP协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次Http请求。Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，Http会立即将TCP连接断开，这个过程是很短的。所以Http连接是一种短连接，常见应用场景是web请求，以及一些弱同步需求的场景，比如部分实时性要求不高的游戏。
TCP：传输控制协议
TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。
面向连接： 面向连接意味着使用tcp的应用程序在传输数据前必须先建立连接，需要三次握手：
客户端主动发起连接，发送syn包，server受到包后，同时带ACK标志和SYN标志。表示对刚才客户端SYN报文的回应，seq表示序号，双方发出序号的包不一样，但一定是递增的。ACK=x+1表示，已经收到了x包，期望下一个需要为x+1的包。client受到sever的syn报文，在回复一个ACK表示确认。
为什么必须是三次握手？
信道不可靠，数据传输要可靠。三次通信是理论上的最小值(我理解的实际上需要双方互相确认，将SYN和ACK合并为一次了)。参照
可靠性：
1.确认：
接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。
实际开发中可以根据需要是否开启延时确认，响应可能结合在一起，成一个响应，减少协议开销 。
优点：减少了数据段的个数，提高了发送效率
缺点：过多的delay会拉长RTT
2.TCP重传机制
TCP需要重传机制来保证所有的数据包都可以到达。
1）超时重传
超时重传机制用来保证TCP传输的可靠性。每次发送数据包时，发送的数据报都有seq号，接收端收到数据后，会回复ack进行确认，表示某一seq号数据已经收到。发送方在发送了某个seq包后，等待一段时间，如果没有收到对应的ack回复，就会认为报文丢失，会重传这个数据包。
- 快速重传
TCP引入了一种叫Fast Retransmit 的算法，不以时间驱动，而以数据驱动重传。也就是说，如果，包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传。Fast Retransmit的好处是不用等timeout了再重传。
另外一种更好的方式叫：Selective Acknowledgment (SACK)（参看RFC 2018），这种方式需要在TCP头里加一个SACK的东西，ACK还是Fast Retransmit的ACK，SACK则是汇报收到的数据碎版。
3.流量控制
TCP header中有一个Window Size字段，它其实是指接收端的窗口，即接收窗口，用来告知发送端自己所能接收的数据量，从而达到一部分流控的目的。三次握手的过程中双发发送的数据包里就带了各自的winsize，发送端的发送窗口是基于接收端的接收窗口来计算的。
（1）已经发送并且对端确认（Sent/ACKed）---------------发送窗外 缓冲区外
（2）已经发送但未收到确认数据（Sent/UnACKed）-------发送窗内 缓冲区内
（3）允许发送但尚未防的数据（Unsent/Inside）-----------发送窗内 缓冲区内
（4）未发送暂不允许（Unsent/Outside）-------------------发送窗外 缓冲区内
TCP窗口就是这样逐渐滑动，发送新的数据，滑动的依据就是发送数据已经收到ACK，确认对端收到，才能继续窗口滑动发送新的数据。可以看到窗口大小对于吞吐量有着重要影响，同时ACK响应与系统延时又密切相关。
拥塞控制下篇在写，好难写。
