OSI七层网络架构
七层模型（OSI，Open System Interconnection参考模型），是参考是国际标准化组织制定的一个用于计算机或通信系统间互联的标准体系。它是一个七层抽象的模型，不仅包括一系列抽象的术语和概念，也包括具体的协议。 经典的描述如下：
简述每一层的含义：
- 物理层（Physical Layer）：建立、维护、断开物理连接。
- 数据链路层 (Link)：逻辑连接、进行硬件地址寻址、差错校验等。
- 网络层 (Network)：进行逻辑寻址，实现不同网络之间的路径选择。
- 传输层 (Transport)：定义传输数据的协议端口号，及流控和差错校验。
- 会话层（Session Layer）：建立、管理、终止会话。
- 表示层（Presentation Layer）：数据的表示、安全、压缩。
- 应用层 (Application)：网络服务与最终用户的一个接口
每一层利用下一层提供的服务与对等层通信，每一层使用自己的协议。了解了这些，然并卵。但是，这一模型确实是绝大多数网络编程的基础，作为抽象类存在的，而TCP／IP协议栈只是这一模型的一个具体实现。TCP/IP五层网络架构
TCP/IP是Internet的基础，是一组协议的代名词，包括许多协议，组成了TCP/IP协议栈。(里面包括IP协议、ICMP协议、TCP协议。)TCP／IP 有四层模型和五层模型之说，区别在于数据链路层是否作为独立的一层存在。
数据是如何传递呢？这就要了解网络层和传输层的协议，我们熟知的IP包结构是这样的：
IP协议和IP地址是两个不同的概念，这里没有涉及IPV6的。不关注网络安全的话，对这些结构不必耳熟能详的。传输层使用这样的数据包进行传输，传输层又分为面向连接的可靠传输TCP和数据报UDP。TCP的包结构：
TCP 连接建立的三次握手肯定是必知必会，在系统调优的时候，内核中关于网络的相关参数与这个图息息相关。UDP是一种无连接的传输层协议，提供的是简单不可靠的信息传输。协议结构相对简单，包括源和目标的端口号，长度以及校验和。基于TCP和UDP的数据封装及解析示例如下：
TCP协议连接、释放过程
TCP/IP分层：
- 有几个需要注意的知识点：
- 互联网地址：也就是IP地址，一般为网络号+子网号+主机号
- 域名系统：通俗的来说，就是一个数据库，可以将主机名转换成IP地址
- RFC：TCP/IP协议的标准文档
- 端口号：一个逻辑号码，IP包所带有的标记
- Socket：应用编程接口
- 数据链路层的工作特性：
- 为IP模块发送和接收IP数据报
- 为ARP模块发送ARP请求和接收ARP应答（ARP：地址解析协议，将IP地址转换成MAC地址）
- 为RARP发送RARP请求和接收RARP应答
- 首先我们先来了解TCP报文段
重要的标志我在图中也有标记，重点了解标志位：
- ACK：确认序号有效
- RST：重置连接
- SYN：发起了一个新连接
- FIN：释放一个连接
三次握手的过程（客户端我们用A表示，服务器端用B表示）
前提：A主动打开，B被动打开
- 在建立连接之前，B先创建TCB（传输控制块），准备接受客户进程的连接请求，处于LISTEN（监听）状态
- A首先创建TCB，然后向B发出连接请求，SYN置1，同时选择初始序号seq=x，进入SYN-SEND（同步已发送）状态
- B收到连接请求后向A发送确认，SYN置1，ACK置1，同时产生一个确认序号ack=x+1。同时随机选择初始序号seq=y，进入SYN-RCVD（同步收到）状态
A收到确认连接请求后，ACK置1，确认号ack=y+1，seq=x+1，进入到ESTABLISHED（已建立连接）状态。向B发出确认连接，最后B也进入到ESTABLISHED（已建立连接）状态。
简单来说，就是:建立连接时，客户端发送SYN包（SYN=i）到服务器，并进入到SYN-SEND状态，等待服务器确认,服务器收到SYN包，必须确认客户的SYN（ack=i+1）,同时自己也发送一个SYN包（SYN=k）,即SYN+ACK包，此时服务器进入SYN-RECV状态,客户端收到服务器的SYN+ACK包，向服务器发送确认报ACK（ack=k+1）,此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。四次分手的过程（客户端我们用A表示，服务器端用B表示）
由于TCP连接时是全双工的，因此每个方向都必须单独进行关闭。这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的链接。收到一个FIN只是意味着这一方向上没有数据流动，既不会在收到数据，但是在这个TCP连接上仍然能够发送数据，知道这一方向也发送了FIN，首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。
前提：A主动关闭，B被动关闭
有人可能会问，为什么连接的时候是三次握手，而断开连接的时候需要四次挥手？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再 发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。A发送一个FIN，用来关闭A到B的数据传送，A进入FIN_WAIT_1状态。
- B收到FIN后，发送一个ACK给A，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），B进入CLOSE_WAIT状态。
- B发送一个FIN，用来关闭B到A的数据传送，B进入LAST_ACK状态。
- A收到FIN后，A进入TIME_WAIT状态，接着发送一个ACK给B，确认序号为收到序+1，B进入CLOSED状态，完成四次挥手。
简单来说就是
客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。 - 服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
- 服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。
- 客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。
A在进入到TIME-WAIT状态后，并不会马上释放TCP，必须经过时间等待计时器设置的时间2MSL（最长报文段寿命），A才进入到CLOSED状态。为什么？ - 为了保证A发送的最后一个ACK报文段能够到达B
- 防止“已失效的连接请求报文段”出现在本连接中
OK~是不是很难懂的感觉？那我们来说的“人性化点的”吧三次握手流程 - 客户端发个请求“开门呐，我要进来”给服务器
- 服务器发个“进来吧，我去给你开门”给客户端
- 客户端有很客气的发个“谢谢，我要进来了”给服务器
四次挥手流程 - 客户端发个“时间不早了，我要走了”给服务器，等服务器起身送他
- 服务器听到了，发个“我知道了，那我送你出门吧”给客户端，等客户端走
- 服务器把门关上后，发个“我关门了”给客户端，然后等客户端走（尼玛~矫情啊）
- 客户端发个“我知道了，我走了”，之后自己就走了
l
- CLOSED: 表示初始状态。
- LISTEN: 表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
- SYN_RCVD: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本 上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态 时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
- SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状 态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
- ESTABLISHED:表示连接已经建立了。
- FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别 是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即 进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马 上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
- FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
- TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带 FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
- CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什 么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报 文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
- CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对 方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
参考链接：http://blog.jobbole.com/91841/utm_source=blog.jobbole.com&utm_medium=relatedPosts