OSI网络模型及TCP简介

1、OSI网络模型

OSI：Open System Interconnection，即开放系统互联

1.1 OSI的七层划分

OSI的七层划分，是人为的一种划分，实际上是不存在的！其七层划分，自下至上依次为：物理层、数据链路层、网络层、传输层、会话层、表现层、应用层

物理层

物理层就是布线、光纤、网卡和其他用来将两台网络通信设备连在一起的东西。网关工作在这一层！这层传输的数据是bite流。

其作用有：
- 0）定义物理设备的标准，如：网线的类型、光纤的接口类型、各种传输介质的传输速率等
- 1）提供数据传输的通路
- 2）传输bite流的数据
数据链路层

数据链路层传输的是帧数据，所采用的协议是Ethernet协议，即以太网协议。Ethernet协议将一组电信号称为一个数据包，即帧！帧由帧头、帧数据、帧尾构成。交换机工作在这一层！该层传输的数据是帧。

帧头包括：
- 发送者地址
- 接收者地址
- 数据类型
其作用：
- 1）封装成帧，即实现如何格式化数据
- 2） MAC寻址
网络层

网络层采用ip协议，其有一个ip地址，表一个网络子网。路由器工作这一层！这层传递的数据包。

其作用：
- 0）将网络地址转换为物理地址
- 1）网络连接建立与管理
- 2）路径选择及中继
- 3）网络连接与重置，报告不可恢复的错误
传输层

提供端口到端口的通信。端口的范围为0_65535，01023为系统占用端口。端口即应用程序与网卡关联的编号。

采用的协议有：TCP协议和UDP协议。

TCP协议，可靠传输，包长没有限制，理论上可以无限长，但是为了保证网络的效率，通常TCP数据包的长度不会超过IP数据包的长度，以确保单个TCP数据包不必在分割。

UDP协议，不可靠传输，报头部分只有8个字节，总长度不超过65535，正好放进一个IP数据包。
会话层

作用：建立、管理、终止应用程序之间的会话和数据交换。
表现层

作用：获取数据并格式以供网络通信使用
应用层

该层使用的http协议。

作用：规定应用程序的数据格式，存在数据的封装和拆包过程。

2、TCP协议

TCP，Transmission Control Protocol，传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。

2.1、TCP的特点

面向连接的、可靠的。基于字节流的传输层协议
将应用层的数据流分割成报文段并发送给目标节点的TCP层
数据包都有序号，对方收到则发送ACK确认，未收到则重传
使用校验和来检验数据在传输过程中是否有误

2.2、TCP的三次握手过程

第一次握手：A客户进程向B发出连接请求报文段，（首部的同步位SYN=1，初始序号seq=x），（SYN=1的报文段不能携带数据）但要消耗掉一个序号，此时TCP客户进程进入SYN-SENT（同步已发送）状态。
第二次握手：B收到连接请求报文段后，如同意建立连接，则向A发送确认，在确认报文段中（SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y），TCP服务器进程进入SYN-RCVD（同步收到）状态；
第三次握手：TCP客户进程收到B的确认后，要向B给出确认报文段（ACK=1，确认号ack=y+1，序号seq=x+1）（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。TCP连接已经建立，A进入ESTABLISHED（已建立连接）。当B收到A的确认后，也进入ESTABLISHED状态。

简单描述TCP的三次握手：

第一次握手：建立连接时，客户端发送SYN包（SYN=1）数据，携带seq=x到服务器，此时客户端进入SYN_SEND状态；
第二次握手：服务器收到SYN包后，服务端确定客户端的SYN包，向客户端发送SYN+ACK包数据（SYN=1，ACK=1），携带seq=y，ack=x+1（确认编号=发送过来数据的seq+数据长度+1），此时服务端进入SYN_RECV状态；
第三次握手：客户端收到服务的SYN+ACK包后，向服务器发送ACK包数据（ACK=1）,携带ack=y+1，此时客户端进入ESTABLISHED状态，服务收到后也将进入ESTABLISHED状态，此时三次握手完成。

2.2.1 TCP三次握手中存在的问题

2.2.1 SYN Flood攻击

SYN Flood 攻击：

TCP连接建立时，客户端通过发送SYN报文发起向处于监听状态的服务器发起连接，服务器为该连接分配一定的资源，并发送SYN+ACK报文。对服务器来说，此时该连接的状态称为半连接(Half-Open)，而当其之后收到客户端回复的ACK报文后，连接才算建立完成。在这个过程中，如果服务器一直没有收到ACK报文(比如在链路中丢失了)，服务器会在超时后重传SYN+ACK。

如果经过多次超时重传后，还没有收到, 那么服务器会回收资源并关闭半连接，仿佛之前最初的SYN报文从来没到过一样！

这看上一切正常，但是如果有坏人故意大量不断发送伪造的SYN报文，那么服务器就会分配大量注定无用的资源，并且从backlog的意义中可知，服务器能保存的半连接的数量是有限的！所以当服务器受到大量攻击报文时，它就不能再接收正常的连接了。换句话说，它的服务不再可用了！这就是SYN Flood攻击的原理。

SYN Cookie技术可以让服务器在收到客户端的SYN报文时，不分配资源保存客户端信息，而是将这些信息保存在SYN+ACK的初始序号和时间戳中。对正常的连接，这些信息会随着ACK报文被带回来。

2.3、TCP数据传输

建立连接后，两台主机就可以相互传输数据了。如下图所示：

上图给出了主机A分2次（分2个数据包）向主机B传递200字节的过程。首先，主机A通过1个数据包发送100个字节的数据，数据包的 Seq 号设置为 1200。主机B为了确认这一点，向主机A发送 ACK 包，并将 Ack 号设置为 1301。

为了保证数据准确到达，目标机器在收到数据包（包括SYN包、FIN包、普通数据包等）包后必须立即回传ACK包，这样发送方才能确认数据传输成功。

此时 Ack 号为 1301 而不是 1201，原因在于 Ack 号的增量为传输的数据字节数。假设每次 Ack 号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确100字节全部正确传递还是丢失了一部分，比如只传递了80字节。因此按如下的公式确认 Ack 号：Ack号 = Seq号 + 传递的字节数 + 1。与三次握手协议相同，最后加 1 是为了告诉对方要传递的 Seq 号。

2.4、TCP的四次挥手

1）客户端进程发出连接释放报文，并且停止发送数据（客户端单方面停止发送数据）。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时客户端的TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCP后，才进入CLOSED状态。
6）**服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCP后，就结束了这次的TCP连接。**可以看到，服务器结束TCP连接的时间要比客户端早一些。

挥手过程简述：

第一次挥手：客户端发送一个FIN包（FIN=1），用来关闭客户端到服务的数据传送，并携带一个序列号seq=u，此时客户端进入FIN_WAIT_1（终止等待1状态）
第二次挥手，服务器收到客服端发送的FIN包后，发送一个ACK包（ACK=1）给客服端，并携带ack=u+1（确认编号）、序列号seq=v，此时服务器进入CLOSE_WAIT（关闭等待）状态
第三次挥手，服务待最后报文发送完毕后，向客服端发送一个FIN+ACK包（FIN=1，ACK=1），用来关闭服务器到客户端的数据传送，并携带一个序列号seq=w、确认序列号ack=u+1，此时服务器进入LAST_ACK（最后确认）状态
第四次挥手，客服端收服务器发送的FIN+ACK包后，客服端进入TIME_WAIT（时间等待）状态，并向服务器发一个ACK（ACK=1），并携带一个确认编号ack=w+1，序列号seq=u+1。服务器收到ACK包后，进入CLOSE状态，断开TCP连接。客服端经过2*MSL（2个最长报文生存时间）后，进入CLOSE状态，断开TCP连接。

常见面试题
【问题1】 为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手

【问题2】 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题3】 为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

【问题4】 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。