详解OSI七层网络模型 TCP/IP四层模型

@TOC这里对OSI七层网络模型和TCP/IP四层模型及其下的各层和TCP协议的设计核心做出总结供大家参考，如有错误欢迎指出讨论！

OSI七层网络模型 & TCP/IP四层模型

OSI七层模型（Open System Interconnection，开放系统互连）
是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系。它是一个七层的、抽象的模型，不仅包括一系列抽象的术语或概念，也包括具体的协议。
TCP/IP四层模型
TCP/IP是一组协议的代名词，它还包括许多协议，组成了TCP/IP协议簇。TCP/IP协议簇分为四层，IP位于协议簇的第二层(对应OSI的第三层)，TCP位于协议簇的第三层(对应OSI的第四层)。之所以命名为TCP/IP协议，因为TCP,IP协议是两个很重要的协议，就用他两命名了。

OSI七层网络模型 & TCP/IP四层模型比对

OSI七层模型各层（传说中的：物.数.网.传.会.表.应.）

物理层：
主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流（就是由1、0转化为电流强弱来进行传输,到达目的地后在转化为1、0，也就是我们常说的数模转换与模数转换）。这一层的数据叫做比特。
数据链路层：
定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。
网络层：
在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。Internet的发展使得从世界各站点访问信息的用户数大大增加，而网络层正是管理这种连接的层。
传输层：
定义了一些传输数据的协议和端口号（WWW端口80等），如：TCP（传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协议，与TCP特性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如QQ聊天数据就是通过这种方式传输的）。主要是将从下层接收的数据进行分段和传输，到达目的地址后再进行重组。常常把这一层数据叫做段。
会话层：
通过传输层（端口号：传输端口与接收端口）建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求（设备之间需要互相认识可以是IP也可以是MAC或者是主机名）
表示层：
可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如，PC程序与另一台计算机进行通信，其中一台计算机使用扩展二一十进制交换码（EBCDIC），而另一台则使用美国信息交换标准码（ASCII）来表示相同的字符。如有必要，表示层会通过使用一种通格式来实现多种数据格式之间的转换。
应用层：
是最靠近用户的OSI层。这一层为用户的应用程序（例如电子邮件、文件传输和终端仿真）提供网络服务。

TCP/IP四层模型各层

网络接口层：（对应OSI的物理层+数据链路层）
对实际的网络媒体的管理，定义如何使用实际网络（如Ethernet、Serial Line等）来传送数据。
网络互联层：（对应OSI的网络层）
负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机（但不检查是否被正确接收），如网际协议（IP）。
传输层：（对应OSI的传输层）
在此层中，它提供了节点间的数据传送服务，如传输控制协议（TCP）、用户数据报协议（UDP）等，TCP和UDP给数据包加入传输数据并把它传输到下一层中，这一层负责传送数据，并且确定数据已被送达并接收。
应用层：（对应OSI的会话层+表示层+应用层）
应用程序间沟通的层，如简单电子邮件传输（SMTP）、文件传输协议（FTP）、网络远程访问协议（Telnet）、HTTP协议和DNS协议等。

HTTP协议（OSI应用层—TCP/IP应用层）

HTTP（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

URL：网址、连接。
https://blog.csdn.net/wener521

ip地址不太方便记忆和传播，用一些更好记忆的字符串来表示域名，浏览器在访问域名的时候会自动把域名转成ip地址。

1. HTTP请求格式：

HTTP请求由三部分组成，分别是：请求行、消息报头、请求正文。

a. 请求行：

Method Request-URI HTTP-Version（三部分空格隔开）

其中：

Method表示请求方法；
Request-URI是一个统一资源标识符；
HTTP-Version表示请求的HTTP协议版本。

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET　　　    请求获取Request-URI所标识的资源
POST　　     在Request-URI所标识的资源后附加新的数据（GET请求往往把自制数据放在quary_string中，POST请求往往把自定制数据放在body中）
HEAD　　　   请求获取由Request-URI所标识的资源的响应消息报头
PUT　　　　  请求服务器存储一个资源，并用Request-URI作为其标识
DELETE　　   请求服务器删除Request-URI所标识的资源
TRACE　　    请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT　    保留将来使用
OPTIONS　    请求查询服务器的性能，或者查询与资源相关的选项和需求

b. 消息报头（header）：若干个键值对，每个键值对占一行，每个键和值之间使用：分割。header部分结束的标记：空行。

c. 请求正文（body）：一般GET请求没有body，POST请求才有。

2. HTTP响应格式：

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文。

a. 状态行：

HTTP-Version Status-Code Reason-Phrase（三部分也是空格隔开）

其中：

HTTP-Version表示服务器HTTP协议的版本；
Status-Code表示服务器发回的响应状态代码；
Reason-Phrase表示状态代码的文本描述。

状态码：
1xx：指示信息–表示请求已接收，继续处理；
2xx：成功–表示请求已被成功接收、理解、接受；
3xx：重定向–要完成请求必须进行更进一步的操作；
4xx：客户端错误–请求有语法错误或请求无法实现；
5xx：服务器端错误–服务器未能实现合法的请求。

常见状态码：

100             //客户端应当继续发送请求
200 OK          //客户端请求成功
301             //永久重定向
302             //临时重定向
400 Bad Request      //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized     //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden        //服务器收到请求，但是拒绝提供服务
404 Not Found        //请求资源不存在，eg：输入了错误的URL
418 I’am a teapot    //我是一个茶壶/杯具(彩蛋)
500 Internal Server Error  //服务器发生不可预期的错误
502 Bad Gateway            //服务器挂了
503 Server Unavailable     //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
504 Gateway Timeout        //服务器响应超时

b. 消息报头（header）：任然是一组键值对，每个键值对占一行每个键和值之间用：分割。header部分的结束标记：空行。
c. 响应正文（body）：响应中的正文格式也有很多种，比如可以是一个html，也可以是一个css，也可以是一个JavaScript，还可以是一个图片数据，还可以是一个json数据…

常见的header：

a. Content-Type：描述了body的数据格式类型；
b. Content-Length：描述了body的数据长度（字节Byte）；
c. Host：描述了访问的主机名（域名/ip）；
d. Referer：当前页面是从哪个页面跳转过来的；
e. Cookie：字符串，浏览器的本地存储的能力之一，中经常会包含一种叫做“身份标识”的信息（session id）；
Session：服务器端维护的一个数据结构，记录了用户的身份信息，session id就是session对象的唯一身份标识，session id报案存在浏览器中，浏览器后续在访问服务器的时候，就会自动带着session id，从而让服务器知道当前请求是哪个用户发来的。
服务器端使用一个hash table之类的结构来维护若干个用户的身份信息，key就是session id，value就是完整的session对象。
Cookie是按照Host这个header来划分的；
f. User-Agent：会告诉网站服务器，访问者是通过什么工具来请求的，手机还是电脑等。

HTTP协议与HTTPS协议的区别

HTTP协议传输的数据都是未加密的，也就是明文的。因此使用HTTP协议传输隐私信息非常的不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
HTTP的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。

TCP协议&UDP协议的区别（OSI传输层—TCP/IP传输层）

**UDP协议**                            **TCP协议**无连接                                     有链接不可靠                                 可靠传输面向数据报                              面向字节流全双工                                  全双工
对系统资源的要求：少                  对系统资源的要求：较多
UDP可能丢包                          TCP保证数据正确性
UDP不能保证数据顺序                   TCP能保证数据顺序

TCP协议的设计核心（可靠性传输+传输效率）

可靠性传输：发送者能知道自己发送成功或者失败。
传输效率：可靠性的前提下尽量提高传输效率。

可靠性传输：（确认应答—超时重传—链接管理）
一．确认应答：
保证可靠性的核心机制。

二．超时重传：
也是可靠传输中最核心的机制。传输一条数据没有确认应答的时候，等待一段时间，然后进行重传，重传可能会重复若干次，重传的次数越多，丢包的概率也就越小，重传的等待时间间隔也再依次变长。

三．链接管理

建立连接的意义：

双方各自试探对方看看对方是否合适和我建立连接，双方的读写数据能力。
双方可以在建立连接的过程中协商一些必要的数据，TCP的序号的基准值。

三次握手具体过程：（三次握手中间两次100%是合在一起的）

客户端发送SYN（Synchronize sequence numbers）标志位为1和ACK（Acknowledgment Number）标志位为0，seq（Sequence Number）为x的连接请求报文段，然后客户端进入SYN_SEND状态，等待服务器的确认响应；（客户端发送SYN同步报文段）
服务器收到客户端的连接请求，对这个SYN报文段进行确认，然后发送ACK为x+1(Seq+1)，SYN标志位和ACK标志位均为1，seq为y的报文段（即SYN+ACK报文段）给客户端，此时服务器进入SYN_RECV状态；（服务器端发送SYN+ACK）
客户端收到服务器的SYN+ACK报文段，确认ACK后，发送ACK为y+1，SYN标志位为0，ACK标志位为1的报文段，发送完成后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手，客户端和服务器端成功地建立连接，可以开始传输数据了。（客户端发送一个ACK）

四次挥手具体过程：（四次挥手中中间两次操作可能合在一起，也可能不合）

客户端发送seq为x+2，ACK为y+1的FIN报文段，客户端进入FIN_WAIT_1状态，即告诉服务端没有数据需要传输了，请求关闭连接；
服务端收到客户端的FIN报文段后，向客户端应答一个ACK为seq（x+3）的ACK报文段，即应答客户端你的请求我收到了，但是我还没准备好，请等待我的关闭请求。客户端收到后进入FIN_WAIT_2状态；
服务端完成数据传输后向客户端发送seq为y+1的FIN报文段，请求关闭连接，服务器进入LAST_ACK状态；
客户端收到服务端的FIN报文段后，向服务端应答一个ACK为seq+1（y+2）的ACK报文段，然后客户端进入TIME_WAIT状态；服务端收到客户端的ACK报文段后关闭连接进入CLOSED状态，客户端等待2MSL后依然没有收到回复，则证明服务端已正常关闭，客户端此时关闭连接进入CLOSED状态。

TIME_WAIT：虽然此时程序可能都已经结束了，但是还是要保持连接为TIME_WAIT状态一段时间，因为发送的最后一个ACK可能会丢包。TIME_WAIT等待的时间是2MSL。
MSL：网络上两个主机之间数据传输的理论最大时间，在Centos7上默认的是60s

传输效率：（滑动窗口—流量控制—拥塞控制—延时应答—捎带应答）
四．滑动窗口：窗口越大，传输效率就越高。

    窗口：不等待ACK的情况下批量发送多少数据。滑动：每次收到一个ACK之后，就依次发送下一条数据，等待ACK的数据区之间就在往后移动。

可靠性：如果窗口无限大，那么接收端可能处理不过来，网络环境也可能承载不了。

如果在滑动窗口过程中丢包了怎么办？

如果是ACK丢了，没有影响，确认序号（ACK）表示的含义是当前序号之前的数据
都收到了，后一个ACK就能涵盖前一个ACK的含义；
如果是数据丢了，接收端就会反复尝试索要该丢掉的数据（通过ACK索要），重复若干次之后，发送端就会认为丢包，并重传对应的数据，而对于已经发送成功的数据，则没必要重新传输一遍（接收端会检查收到的数据，并回复最新的确认序号ACK，所以没必要重传已经发送成功的数据）。

五．流量控制：通过接收端的处理能力（接收缓冲区）来限制滑动窗口大小的一种机制

接收端的接收缓冲区的剩余空间，用这个数字来衡量接收端的处理能力；
接收缓冲区剩余空间越大，就认为处理能力越强；
接收缓冲区剩余空间越小，就认为处理能力越差。

六．拥塞控制：通过限制发送端的发送速率来限制滑动窗口大小的一种机制

试探式的方式：

刚开始的时候，使用比较小的滑动窗口，如果这个时候没有丢包，说明网络很通畅，增大滑动窗口；
如果发生丢包，说明网络可能拥堵了，减小滑动窗口。

发送端真实的滑动窗口大小= min（流量控制中滑动窗口的大小，拥塞控制中滑动窗口的大小）

七．延时应答：提高传输效率的方式，尽可能的提高窗口的大小。
延时应答导致延时时间中，接收端的程序已经处理了一部分的数据，此时ACK中的窗口大小就更大了。

八．捎带应答：延时应答的基础上，再提高效率。
延时应答的基础之上，把应用程序发送的业务数据和系统发送的ACK数据合二为一。

九．图览：

Cookie和Session的区别

cookie数据存放在客户的浏览器上，session数据放在服务器上；
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session；
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用COOKIE；
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie；
建议：
将登陆信息等重要信息存放为SESSION；
其他信息如果需要保留，可以放在COOKIE中。
Session对象在浏览器中的有效范围：
IE中:
a. Session对象只在建立Session对象的窗口中有效；
b. 在建立Session对象的窗口中新开链接的窗口也有效。
Session只会在内存中，他会随着IE窗口的关闭而死亡；
也就是说单用seesion是不会有产生自动登入的效果的。
Cookie 是在服务器给客户端IE一个命令后在客户端产生并存的，它可以存放用户信息，存到客户端硬盘上，在COOKIE记录被删除或者失效日期之前，就可以实现自动登入的现象；
Session 和 Cookie 是不同的，但是他们确实是相关的。
当打开IE登入后，会向服务器发出一个指令请求SESSIONID以及页面内容，服务器会返回页面内容和一个没有被使用的SESSIONID让此IE使用，当时IE就对返回SESSIONID做存储；而当此IE再访问任何这个站点的JSP程序的时候,都会给服务器这个 SESSIONID，来确认客户端的身份（在没有Cookie 的情况下session死亡 SESSIONID被取消就需要重新登入）。