189 8069 5689
OSI模型 作用
应用层 为应用程序提供服务支持
表示层 将数据格式进行转换、加密
会话层 建立会话、管理会话、维护会话
传输层 建立、管理、维护端到端的连接
网络层 IP选址、路由选择
数据链路层 提供介质访问和链路管理
物理层 底层物理支持
l 物理层：位于最低层，是传送信号的物理实体，主要解决两台物理机之间的通信。它的功能是：通过机械和电气的方式将各站点连接起来，组成物理通路，通过二进制比特流的传输来实现，二进制数据表现为电流电压上的强弱，到达目的地再转化为二进制机器码。网卡、集线器工作在这一层。
2 数据链路层：在不可靠的物理介质上提供可靠的传输，接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层。这一层在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路。提供物理地址寻址功能。交换机工作在这一层。
3 网络层：处理报文分组，完成分组的多路复用和分组交换，以及通信子网络间的数据据传输，将网络地址翻译成对应的物理地址，并决定如何将数据从发送方路由到接收方，通过路由协议为分组通过通信子网选择最佳路径。路由器工作在这一层。
4 传输层：实现端点到端点的可靠数据传输，区分不同进程和服务。
5 会话层：用于建立、控制和终止终端用户的实用进程间的逻辑信道的连接，并提供支持同步和管理应用进程间的对话服务，验证会话双方的身份，恢复下位层不呆恢复的差错。
6 表示层：对数据格式进行编译，对收到或发出的数据根据应用层的特征进行处理，如处理为文字、图片、音频、视频、文档等，还可以对压缩文件进行解压缩、对加密文件进行解密等。
7 应用层：功能实现依托不同的应用层协议，如HTTP协议，FTP协议等等，方便应用程序之间进行通信，为用户服务。
划分七层模型的好处：
l 易于标准化
不同层次之间功能和目的具有明显差异，界线清楚，可使复杂的网络设计简化清晰。
2 灵活性—降低不同层次之间的关联性
网络中各层相对独立，修改了某层协议也不会影响系统的其他部分。不同层次完成的职能不同，每层只完成有限的功能，上层请求下层的服务，下层实现上层的意图。
OSI 参考模型注重“通信协议必要的功能是什么”，而 TCP/IP 则更强调“在计算机上实现协议应该开发哪种程序”。
相同点
OSI 参考模型与 TCP/IP 参考模型都采用了层次结构。
都能够提供面向连接和无连接两种通信服务机制。
不同点
OSI 采用的七层模型； TCP/IP 是四层结构。
TCP/IP 参考模型没有对网络接口层进行细分，只是一些概念性的描述； OSI 参考模型对服务和协议做了明确的区分。
OSI 先有模型，后有协议规范，适合于描述各种网络；TCP/IP 是先有协议集然后建立模型，不适用于非 TCP/IP 网络。
TCP/IP 一开始就提出面向连接和无连接服务，而 OSI 一开始只强调面向连接服务，直到很晚才开始制定无连接的服务标准。
OSI 参考模型虽然被看好，但将网络划分为七层，实现起来较困难；相反，TCP/IP 参考模型虽然有许多不尽人意的地方，但作为一种简化的分层结构还是比较成功的。
封装—数据从应用层传输到物理层的过程
解封装-收到数据包，数据从物理层还原到应用层的过程
完整过程总结：
1）应用层 当数据传送到应用层时，应用层为数据加上应用层报头， 组成应用层的协议数据单元，再传送到表示层。
2）表示层 表示层接收到应用层数据单元后，加上表示层报头组成表示层协议数据单元，再传送到会话层。表示层按照协议要求对数据进行格式变换和加密处理。
3）会话层 会话层接收到表示层数据单元后，加上会话层报头组成会话层协议数据单元，再传送到传输层。会话层报头用来协调通信主机进程之间的通信
4）传输层 传输层接收到会话层数据单元后，加上传输层报头组成传输 OSI参考模型中数据传输的基本过程层协议数 据单元，再传送到网络层。传输层协议数据单元成为报文 。
5）网络层 网络层接收到传输层报文后，由于网络层协议数据单元的长度有限制，需要将长报文分成多个较短的报文段，加上网络层报头组成网络层协议数据单元，再传送到数据链路层，网络层协议数据单元成为分组。
6）数据链路层 数据链路层接收到网络层分组后，按照数据链路层协议规定的帧格式封装成帧，再传送到物理层，数据链路层协议数据单元称为帧 7）物理层 物理层接收到数据链路层帧之后，将组成帧的比特序列（也称为比特流），通过传输介质传送给下一个主机的物理层。物理层的协议数据单元是比特序列
解封装可以理解为封装的逆过程
概念：
HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。
HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。
HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
HTTPS 默认工作在 TCP 协议443端口
HTTP协议工作过程
概述：
浏览器进行DNS域名解析，得到对应的IP地址
根据这个IP，找到对应的服务器建立连接（三次握手）
建立TCP连接后发起HTTP请求（一个完整的http请求报文）
服务器响应HTTP请求，浏览器得到html代码（服务器如何响应）
浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）
浏览器对页面进行渲染呈现给用户数据传输完成，发送断开连接请求，服务器关闭TCP连接（四次挥手）
区别：
HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
SSL协议可用于保护正常运行于TCP之上的任何应用协议，如HTTP、FTP、SMTP或Telnet的通信，最常见的是用SSL来保护HTTP的通信。
SSL协议的优点在于它是与应用层协议无关的。高层的应用协议（如HTTP、FTP、Telnet等）能透明地建立于SSL协议之上。
SSL协议在应用层协议之前就已经完成加密算法、通信密钥的协商以及服务器的认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的安全性。
作用：
•客户对服务器的身份认证
SSL服务器允许客户的浏览器使用标准的公钥加密技术和一些可靠的认证中心（CA）的证书，来确认服务器的合法性。
•服务器对客户的身份认证
也可通过公钥技术和证书进行认证，也可通过用户名，password来认证。
•建立服务器与客户之间安全的数据通道
SSL要求客户与服务器之间的所有发送的数据都被发送端加密、接收端解密，同时还检查数据的完整性
三次握手
所谓三次握手(Three-way Handshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。
三次握手的目的是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息.在socket编程中，客户端执行connect()时。将触发三次握手
第一次握手:
客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号(Sequence Number)字段里。
第二次握手:
服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。
第三次握手.
客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1（ISN—初始序列号）
四次挥手
TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。
首先，为什么是三次握手而不是四次或者更多？这个问题是比较简单的，因为既然三次能够解决的问题，为什么非要用四次来浪费资源？
但其实问题的重点在于，为什么不能只用两次？第三次握手去掉不行吗？
总的来说，三次握手是为了防止当已失效的连接请求报文段突然又传到服务端，造成双方的不一致，导致资源的浪费。
“已失效的连接请求报文段”指的是这样的情况，客户端发出一个SYN报文段，由于阻塞或者其他原因在网络中滞留，以至于客户端认为丢包了（其实并没有丢），于是重新发出一个SYN报文段，假设这一次顺利完成了，那么双方建立连接。这看起来似乎没什么问题，但网络中有一个隐患，就是那个还在网络中传输的SYN报文段，如果这个SYN在连接期间被服务端收到了，那服务端只会无视它，这样就万事大吉了，但如果是在连接释放之后被收到呢？此时服务端认为有人向他发出连接请求，于是响应一个SYNACK回去，如果采用两次握手的话，那么服务器认为此时连接已经建立好了。但是当客户端收到这个SYNACK时，如果他并没有发起连接，那么他不会理睬这个SYNACK，就当没事发生过（如果客户端此时正好发起连接，那其实他也不会理睬这个SYNACK，因为确认号不对啊。）。那问题就大了，这时候服务器以为连接好了，向客户端发送数据，而客户端处于CLOSED状态，会丢弃这些包，这样就很浪费了。并且还有一个尴尬的问题，就是这个时候当客户端打算发起连接时，服务端又不理睬了，在这里尬这，他们就别想互发数据了。当然这些问题似乎不是不可解决的，当客户端发现服务端老是向自己发数据，而自己总是丢弃，可能会向服务端发一个RST（报文段的RST标记号为1），强制服务端关闭连接。但资源总归是浪费了一会了。而用三次握手就不会出现这样的问题。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧