OSI七层模型和TCP/IP四层模型
OSI七层模型
Open Systems Interconnection Reference Model，是国际标准化组织(ISO)提出的一个网络的标准框架，简称OSI。
| 分层 | 功能 | 传输单位 | 主要协议 |
|---|---|---|---|
| 物理层 | 通过媒介传输比特 | 比特 | IEEE 802.3 CLOCK RJ45 |
| 链路层 | 将比特组装成帧，点到点传递 | 帧 | MAC VLAN PPP |
| 网络层 | 负责数据包从源到宿的传递和网络互联 | 包 | IP ARP ICMP |
| 传输层 | 端到端的可靠报文传递和错误恢复 | 报文 | TCP UDP |
| 会话层 | 建立，管理和终止会话 | SPDU | RPC NFS |
| 表示层 | 对数据进行翻译加密和压缩 | PPDU | JPEG ASII |
| 应用层 | 允许访问OSI环境的手段 | APDU | FTP HTTP DNS |
TCP/IP四层模型
| 分层 | 协议 |
|---|---|
| 网络接口层 | MAC VLAN |
| 网络层 | IP ARP ICMP |
| 传输层 | TCP UDP |
| 应用层 | HTTP DNS SMTP |
TCP协议
TCP报文段结构
***seq:占四个字节，标记数据段顺序（报文段中第一个字节的数据编号）
确认号ack:占四个字节，期待收到对方下一个报文段的第一个数据字节的序号=当前报文段最后一个字节的编号+1
标志位：占1位，值为1/0
确认ACK：仅当ACK=1时，确认号字段才有效。
同步SYN：连接建立时用于同步序号。当SYN=1,ACK=0时表示这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1,ACK=1。只有在TCP建立连接时才会被置为1，握手完成后置为0.
终止FIN：用来释放一个连接。FIN=1表示报文段发送方数据已发送完毕，并要求释放连接。
TCP三次握手和四次挥手
三次握手：
1.Client将标志位SYN置为1，并随机产生一个seq=x值，将该SYN数据包发送给Server，Client进入SYN_SENT状态
2.Server收到数据包后由标志位SYN知道Client请求连接，此时需要确认客户的SYN（ACK=1,ack=x+1），同时自己也发送一个SYN包(SYN=1,seq=随机***y)，即SYN+ACK包，Server进入SYN_RECV状态
3.客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ACK,ack=y+1),TCP连接建立成功，客户端和服务器进入ESTABLISHED状态。
三次握手的原因:防止已经失效的连接请求报文又传输到服务器端造成资源浪费。如客户端先发送了一个SYN，但是由于网络阻塞，该SYN数据包在某个节点长期滞留。然后客户端又重传SYN数据包并正确建立TCP连接，然后传输完数据后关闭该连接。该连接释放后失效的SYN数据包才到达服务器端。在二次握手的前提下，服务器端会认为这是客户端发起的又一次请求，然后发送SYN ，并且在服务器端创建socket套接字，一直等待客户端发送数据。但是由于客户端并没有发起新的请求，所以会丢弃服务端的SYN 。此时服务器会一直等待客户端发送数据从而造成资源浪费。
四次挥手
1.数据传输结束，客户端应用程序发出连接释放报文段，并停止发送数据，客户端进入FIN_WAIT_1状态。（此时客户端依然可以接收服务器发来的数据！！）
2.服务器接收到FIN后，发送一个ACK给客户端，确认号为收到的序号+1，服务器进入CLOSE_WAIT状态。客户端收到后进入FIN_WAIT_2状态。
3.当服务器没有数据要发送时，服务器发送一个FIN报文，进入LAST_ACK状态，等待客户端确认。
4.客户端收到服务器的FIN报文后，回复一个ACK报文，确认号为收到的序号+1。此时客户端进入TIME_WAIT状态，等待2MSL（MSL:报文段最大生存时间），然后关闭连接。
TCP拥塞控制
防止过多的数据注入网络。
在正常的传输过程中，数据是从一个路由器跳到下一个路由器，每个路由器都有自己的缓冲区，新来的数据会存放在缓冲区中，与此同时路由器也在不断地将缓冲区中的数据发送给下一个路由器。但是如果某个路由器接收数据的速率大于发送数据的速率，就会导致缓冲区数据累积，最终填满缓冲区。此时如果再有数据到来，缓冲区已经无法容纳它们，只能将它们丢掉，造成数据丢失，这就是所谓的拥塞现象，本质就是传输路径上的节点不平衡。为了解决这一问题，就需要当出现拥塞现象时立即减少发送端发送的数据量，为路径上的某些节点提供清空缓冲区的时间，同时也避免了不必要的重传。
但是，发送端如何才能得知网络中发生了拥塞呢。因为由于硬件错误造成的数据丢失是很罕见的，所以发送端假定，如果出现了数据丢失，那么就可以认定发生了拥塞。
发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口小于拥塞窗口。
超时重传机制
超时重传主要是为了解决数据包在传输过程中丢失的问题。
TCP每发送一个报文段，就会为这个报文段开启一个定时器，如果定时器溢出时仍然没有收到接收端的应答报文，那么TCP就认为这个报文段在传输过程中丢失，然后重新发送这个报文段。这便是超时重传机制
拥塞控制方法
慢启动：
从小到大逐渐增加拥塞窗口大小（不要开始就发送大量数据，先探测一下网络的拥堵情况）
以报文段个数的拥塞窗口为例：初始为1，每个传输轮次后拥塞窗口翻倍。当超过一个阈值后，改用拥塞避免算法
拥塞避免：
拥塞窗口缓慢增长，每个RTT（往返时间）把拥塞窗口+1。
每当出现拥塞（没有收到确认），就把慢启动阈值设置为当前发送窗口的一半，拥塞窗口置为1，执行慢启动快重传
接收方收到一个失序的报文段后立刻发出重复确认（目的是使发送方尽早知道有报文段没到）。当发送方连收到三个重复确认后就应当立即重传对方未收到的报文段，而不必等待设置的重传计时器超时。
快恢复
· 当发送方连续收到三个重复确认时，执行“乘法减少”算法，阈值减半。
· 此时拥塞窗口大小设置为阈值大小(实际实现是cwnd = ssthresh + 3)，执行拥塞避免算法。why? 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。### 与流量控制区别
·流量控制是端对端的控制，两端各自通知对方允许的窗口大小防止对方发送过多数据造成接收端缓冲区被填满
·用滑动窗口告知接收端缓存大小，以此控制发送数据的大小，达到流量控制的目的
·拥塞控制不是端对端的控制，缓解的是全局的路径的拥堵问题。
TCP用了哪些方法保证其可靠性
1.***，确认号，超时重传
数据到接收方，接收方需要发出一个确认应答，表示收到了该数据段，且确认号会说明它下一次需要接受的数据***。如果迟迟未收到应答，超时重传（2 * RTT）
2.窗口控制与快速重传
TCP使用窗口来提高传输速度，即一个窗口大小内，不必等到应答才能发送下一个数据段，窗口大小表示的就是无需等待确认而可以继续发送数据的最大值。
使用窗口控制，如果数据段1001-2000丢失，后面数据每次传输，确认应答都会不停地发送序号为1001的应答，表示我要接收1001开始的数据，发送端如果收到3次相同应答，就会立刻进行重发；但还有种情况有可能是数据都收到了，但是有的应答丢失了，这种情况不会进行重发，因为发送端知道，如果是数据段丢失，接收端不会放过它的，会疯狂向它提醒…
3.拥塞控制
如果把窗口定的很大，发送端连续发送大量的数据，可能会造成网络的拥堵（大家都在用网，你在这狂发，吞吐量就那么大，当然会堵），甚至造成网络的瘫痪。所以TCP在为了防止这种情况而进行了拥塞控制。
慢启动：定义拥塞窗口，一开始将该窗口大小设为1，之后每次收到确认应答（经过一个rtt），将拥塞窗口大小*2。
拥塞避免：设置慢启动阈值，一般开始都设为65536。拥塞避免是指当拥塞窗口大小达到这个阈值，拥塞窗口的值不再指数上升，而是加法增加（每次确认应答/每个rtt，拥塞窗口大小+1），以此来避免拥塞。
将报文段的超时重传看做拥塞，则一旦发生超时重传，我们需要先将阈值设为当前窗口大小的一半，并且将窗口大小设为初值1，然后重新进入慢启动过程。
快速重传：在遇到3次重复确认应答（高速重发控制）时，代表收到了3个报文段，但是这之前的1个段丢失了，便对它进行立即重传。
快速恢复：快速重传后，先将阈值设为当前窗口大小的一半，然后将拥塞窗口大小设为慢启动阈值+3的大小。
这样可以达到：在TCP通信时，网络吞吐量呈现逐渐的上升，并且随着拥堵来降低吞吐量，再进入慢慢上升的过程，网络不会轻易的发生瘫痪。