OSI分层 (7层):物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。php
TCP/IP分层(4层):网络接口层、 网际层、运输层、 应用层。html
五层协议 (5层):物理层、数据链路层、网络层、运输层、 应用层。java
每一层的做用以下:git
**物理层:**经过媒介传输比特,肯定机械及电气规范(比特Bit)github
数据链路层:将比特组装成帧和点到点的传递(帧Frame)web
网络层:负责数据包从源到宿的传递和网际互连(包PackeT)面试
传输层:提供端到端的可靠报文传递和错误恢复(段Segment)算法
会话层:创建、管理和终止会话(会话协议数据单元SPDU)数据库
表示层:对数据进行翻译、加密和压缩(表示协议数据单元PPDU)浏览器
应用层:容许访问OSI环境的手段(应用协议数据单元APDU)
每一层的协议以下:
物理层:RJ4五、CLOCK、IEEE802.3 (中继器,集线器,网关)
数据链路:PPP、FR、HDLC、VLAN、MAC (网桥,交换机)
网络层:IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 (路由器)
传输层:TCP、UDP、SPX
会话层:NFS、SQL、NETBIOS、RPC
表示层:JPEG、MPEG、ASII
应用层:FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS
互联网协议地址(英语:Internet Protocol Address,又译为网际协议地址),缩写为IP地址(英语:IP Address),是分配给用户上网使用的网际协议(英语:Internet Protocol, IP)的设备的数字标签。常见的IP地址分为IPv4与IPv6两大类,可是也有其余不经常使用的小分类。
版本 : 有 4(IPv4)和 6(IPv6)两个值;
首部长度 : 占 4 位,所以最大值为 15。值为 1 表示的是 1 个 32 位字的长度,也就是 4 字节。由于首部固定长度为 20 字节,所以该值最小为 5。若是可选字段的长度不是 4 字节的整数倍,就用尾部的填充部分来填充。
区分服务 : 用来得到更好的服务,通常状况下不使用。
总长度 : 包括首部长度和数据部分长度。
生存时间 :TTL,它的存在是为了防止没法交付的数据报在互联网中不断兜圈子。以路由器跳数为单位,当 TTL 为 0 时就丢弃数据报。
协议 :指出携带的数据应该上交给哪一个协议进行处理,例如 ICMP、TCP、UDP 等。
首部检验和 :由于数据报每通过一个路由器,都要从新计算检验和,所以检验和不包含数据部分能够减小计算的工做量。
标识 : 在数据报长度过长从而发生分片的状况下,相同数据报的不一样分片具备相同的标识符。
片偏移 : 和标识符一块儿,用于发生分片的状况。片偏移的单位为 8 字节
由两部分组成,网络号和主机号,其中不一样分类具备不一样的网络号长度,而且是固定的。
IP 地址 ::= {< 网络号 >, < 主机号 >}
IP地址分为五大类:A类、B类、C类、D类和E类,以下图所示:
IP地址的指派范围:
通常不使用的特殊IP地址:
ARP 实现由 IP 地址获得 MAC 地址。
1:首先,每一个主机都会在本身的ARP缓冲区中创建一个ARP列表,以表示IP地址和MAC地址之间的对应关系。
2:当源主机要发送数据时,首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址,若是有,则直接发送数据,若是没有,就向本网段的全部主机发送ARP数据包,该数据包包括的内容有:源主机IP地址,源主机MAC地址,目的主机的IP地址。
3:当本网络的全部主机收到该ARP数据包时,首先检查数据包中的IP地址是不是本身的IP地址,若是不是,则忽略该数据包,若是是,则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中,若是已经存在,则覆盖,而后将本身的MAC地址写入ARP响应包中,告诉源主机本身是它想要找的MAC地址。
4:源主机收到ARP响应包后。将目的主机的IP和MAC地址写入ARP列表,并利用此信息发送数据。若是源主机一直没有收到ARP响应数据包,表示ARP查询失败。
广播发送ARP请求,单播发送ARP响应。
TCP(Transmission Control Protocol 传输控制协议)是一种面向链接的、可靠的、基于字节流的传输层通讯协议,由IETF的RFC 793定义。
TCP提供一种面向链接的、可靠的字节流服务。其中,面向链接意味着两个使用TCP的应用(一般是一个客户和一个服务器)在彼此交换数据以前必须先创建一个TCP链接。在一个TCP链接中,仅有两方进行彼此通讯;而字节流服务意味着两个应用程序经过TCP连接交换8bit字节构成的字节流,TCP不在字节流中插入记录标识符。
对于可靠性,TCP经过如下方式进行保证:
数据包校验:目的是检测数据在传输过程当中的任何变化,若校验出包有错,则丢弃报文段而且不给出响应,这时TCP发送数据端超时后会重发数据;
对失序数据包重排序:既然TCP报文段做为IP数据报来传输,而IP数据报的到达可能会失序,所以TCP报文段的到达也可能会失序。TCP将对失序数据进行从新排序,而后才交给应用层;
丢弃重复数据:对于重复数据,可以丢弃重复数据;
应答机制:当TCP收到发自TCP链接另外一端的数据,它将发送一个确认。这个确认不是当即发送,一般将推迟几分之一秒;
超时重发:当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。若是不能及时收到一个确认,将重发这个报文段;
流量控制:TCP链接的每一方都有固定大小的缓冲空间。TCP的接收端只容许另外一端发送接收端缓冲区所能接纳的数据,这能够防止较快主机导致较慢主机的缓冲区溢出,这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方经过 TCP 报文段中的窗口字段告诉发送方本身的窗口大小,发送方根据这个值和其它信息设置本身的窗口大小。
发送窗口内的字节都容许被发送,接收窗口内的字节都容许被接收。若是发送窗口左部的字节已经发送而且收到了确认,那么就将发送窗口向右滑动必定距离,直到左部第一个字节不是已发送而且已确认的状态;接收窗口的滑动相似,接收窗口左部字节已经发送确认并交付主机,就向右滑动接收窗口。
接收窗口只会对窗口内最后一个按序到达的字节进行确认,例如接收窗口已经收到的字节为 {31, 34, 35},其中 {31} 按序到达,而 {34, 35} 就不是,所以只对字节 31 进行确认。发送方获得一个字节的确认以后,就知道这个字节以前的全部字节都已经被接收。
计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就会变坏,这种状况就叫作拥塞。拥塞控制就是 防止过多的数据注入网络中,这样可使网络中的路由器或链路不致过载。
若是网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而致使网络拥塞程度更高。所以当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,可是出发点不一样。流量控制是为了让接收方能来得及接收,而拥塞控制是为了下降整个网络的拥塞程度。
注意,拥塞控制和流量控制不一样,前者是一个全局性的过程,然后者指点对点通讯量的控制。拥塞控制的方法主要有如下四种: A、慢启动 B、拥塞避免 C、快重传 D、快恢复
发送方须要维护一个叫作拥塞窗口(cwnd)的状态变量,注意拥塞窗口与发送方窗口的区别:拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。
为了便于讨论,作以下假设:
A、接收方有足够大的接收缓存,所以不会发生流量控制;
B、虽然 TCP 的窗口基于字节,可是这里设窗口的大小单位为报文段。
慢启动:
不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增长拥塞窗口的大小。
拥塞避免:
拥塞避免算法让拥塞窗口缓慢增加,即每通过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍,这样拥塞窗口按线性规律缓慢增加。
发送的最初执行慢开始,令 cwnd = 1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,所以以后发送方可以发送的报文段数量为:二、四、8 …
注意到慢开始每一个轮次都将 cwnd 加倍,这样会让 cwnd 增加速度很是快,从而使得发送方发送的速度增加速度过快,网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每一个轮次只将 cwnd 加 1。
若是出现了超时,则令 ssthresh = cwnd / 2,而后从新执行慢开始。
快重传:
快重传要求接收方在收到一个 失序的报文段 后就当即发出 重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到本身发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当当即重传对方还没有收到的报文段,而没必要继续等待设置的重传计时器时间到期。
快恢复:
快重传配合使用的还有快恢复算法,当发送方连续收到三个重复确认时,就执行“乘法减少”算法,把ssthresh门限减半,可是接下去并不执行慢开始算法:由于若是网络出现拥塞的话就不会收到好几个重复的确认,因此发送方如今认为网络可能没有出现拥塞。因此此时不执行慢开始算法,而是将cwnd设置为ssthresh的大小,而后执行拥塞避免算法。
在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。
在发送方,若是收到三个重复确认,那么能够知道下一个报文段丢失,此时执行快重传,当即重传下一个报文段。例如收到三个 M2,则 M3 丢失,当即重传 M3。
在这种状况下,只是丢失个别报文段,而不是网络拥塞。所以执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。
慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增加速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。
TCP流量控制的流程图:
SYN:同步SYN(SYNchronization),在链接创建使用来同步序号。SYN置1表示这是一个链接请求或链接接受请求。
ACK:确认ACK(ACKnowledgment),仅当ACK=1时确认号字段才有效。TCP规定,在链接创建后全部的报文段都必须把ACK置1。
seq: 序号。
ack: 确认号。
最初两端的TCP进程都处于CLOSE(关闭)状态。
上图中A主动打开链接,B被动打开链接。
B打开链接后处于LISTEN(监听状态),等待客户的链接请求。
A向B发送请求报文,SYN=1,ACK=0,选择一个初始序号seq=x。
B 收到链接请求报文,若是赞成创建链接,则向 A 发送链接确认报文,SYN=1,ACK=1,确认号为ack= x+1,同时也选择一个初始的序号 seq=y。
A 收到 B 的链接确认报文后,还要向 B 发出确认,确认号为ack= y+1,序号为 seq=x+1。
B 收到 A 的确认后,链接创建。
数据传输结束后,通讯的双方均可释放链接。
此处为A的应用进程先向其TCP发出链接释放报文段,可是A结束TCP链接的时间要比B晚一些。
FIN: 终止FINs,用来释放一个链接。当FIN等于1时,代表此报文段的发送方的数据已发送完毕,并要求释放运输链接。
ACK: 确认ACK(ACKnowledgment),仅当ACK=1时确认号字段才有效。TCP规定,在链接创建后全部的报文段都必须把ACK置1。
seq: 序号。
ack: 确认号。
如下描述不讨论序号和确认号,由于序号和确认号的规则比较简单。而且不讨论 ACK,由于 ACK 在链接创建以后都为 1。
四次挥手的缘由
CLOSE-WAIT
客户端发送了 FIN 链接释放报文以后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕以后,服务器会发送 FIN 链接释放报文。
TIME-WAIT
客户端接收到服务器端的 FIN 报文后进入此状态,此时并非直接进入 CLOSED 状态,还须要等待一个时间计时器设置的时间 2MSL。
为何A在TIME-WAIT状态必须等待2MSL的时间呢?
这么作有两个理由:
为了保证A发送的最后一个ACK报文段可以到达B。
A发送的这个ACK报文段有可能丢失,若是 B 没收到 A 发送来的确认报文,那么A就会从新发送链接释放请求报文,A 等待一段时间就是为了处理这种状况的发生。
防止“已经失效的链接请求报文段”出如今本连接中。
A在发送完最后一个ACK报文段后,再通过时间2MSL,就可使本链接的时间内所产生的全部报文段都从网络中消失。这样下一个新的链接中就不会出现这种旧的链接请求报文段。
这是由于服务端的LISTEN状态下的SOCKET当收到SYN报文的链接请求后,它能够把ACK和SYN(ACK起应答做用,而SYN起同步做用)放在一个报文里来发送。但关闭链接时,当收到对方的FIN报文通知时,**它仅仅表示对方没有数据发送给你了;但未必你全部的数据都所有发送给对方了,**因此你可能未必会立刻会关闭SOCKET,也即你可能还须要发送一些数据给对方以后,再发送FIN报文给对方来表示你赞成如今能够关闭链接了,因此它这里的ACK报文和FIN报文多数状况下都是分开发送的。
用户数据包协议(英语:User Datagram Protocol,缩写:UDP),又称用户数据包协议,是一个简单的面向数据报的传输层协议。该协议由 David P. Reed 在 1980 年设计且在RFC 768中被规范。
在TCP/IP模型中,UDP为网络层以上和应用层如下提供了一个简单的接口。UDP只提供数据的不可靠传递,它一旦把应用程序发给网络层的数据发送出去,就不保留数据备份(因此UDP有时候也被认为是不可靠的数据报协议)。UDP在IP数据报的头部仅仅加入了复用和数据校验(字段)
TCP面向链接,传输数据以前要须要创建会话。UDP是无链接的。
TCP提供可靠传输,保证数据不丢包、不重复且按顺序到达;UDP只尽努力交付,不保证可靠交付
TCP提供了拥塞控制;UDP不提供
TCP是面向字节流的;UDP面向报文。
TCP只支持点到点通讯;UDP支持一对1、一对多、多对多的交互通讯。
TCP首部开销大20字节,UDP首部开销小8字节。
UDP的首部格式
TCP的首部格式
1). TCP对应的应用层协议
2). UDP对应的应用层协议
超文本传输协议(英语:HyperText Transfer Protocol,缩写:HTTP)是一种用于分布式、协做式和超媒体信息系统的应用层协议[1]。HTTP是万维网的数据通讯的基础。
HTTP协议定义了浏览器(即互联网客户进程)怎样向万维网文档,以及服务器怎样把文档传送给浏览器。从层次的角度看,HTTP是面向事务的应用层协议,它是万维网可以可靠的交付文件的重要基础。
HTTP协议中共定义了八种方法或者叫“动做”来代表对Request-URI指定的资源的不一样操做方式,具体介绍以下:
GET:向特定的资源发出请求。
POST:向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会致使新的资源的建立和/或已有资源的修改。
OPTIONS:返回服务器针对特定资源所支持的HTTP请求方法。也能够利用向Web服务器发送’*'的请求来测试服务器的功能性。
HEAD:向服务器索要与GET请求相一致的响应,只不过响应体将不会被返回。这一方法能够在没必要传输整个响应内容的状况下,就能够获取包含在响应消息头中的元信息。
PUT:向指定资源位置上传其最新内容。
DELETE:请求服务器删除Request-URI所标识的资源。
TRACE:回显服务器收到的请求,主要用于测试或诊断。
CONNECT:HTTP/1.1协议中预留给可以将链接改成管道方式的代理服务器。
虽然HTTP的请求方式有8种,可是咱们在实际应用中经常使用的也就是get和post,其余请求方式也均可以经过这两种方式间接的来实现。
摘自:https://www.cnblogs.com/web100/p/http-8-request.html
GET与POST是咱们经常使用的两种HTTP Method,两者之间的区别主要包括以下五个方面:
(1). 从功能上讲,GET通常用来从服务器上获取资源,POST通常用来更新服务器上的资源;
(2). 从REST服务角度上说,GET是幂等的,即读取同一个资源,老是获得相同的数据,而POST不是幂等的,由于每次请求对资源的改变并非相同的;进一步地,GET不会改变服务器上的资源,而POST会对服务器资源进行改变;
(3). 从请求参数形式上看,GET请求的数据会附在URL以后,即将请求数据放置在HTTP报文的 请求头 中,以?分割URL和传输数据,参数之间以&相连。特别地,若是数据是英文字母/数字,原样发送;不然,会将其编码为 application/x-www-form-urlencoded MIME 字符串(若是是空格,转换为+,若是是中文/其余字符,则直接把字符串用BASE64加密,得出如:%E4%BD%A0%E5%A5%BD,其中%XX中的XX为该符号以16进制表示的ASCII);而POST请求会把提交的数据则放置在是HTTP请求报文的 请求体 中。
(4). 就安全性而言,POST的安全性要比GET的安全性高,由于GET请求提交的数据将明文出如今URL上,并且POST请求参数则被包装到请求体中,相对更安全。
(5). 从请求的大小看,GET请求的长度受限于浏览器或服务器对URL长度的限制,容许发送的数据量比较小,而POST请求则是没有大小限制的。
状态代码有三位数字组成,第一个数字定义了响应的类别,且有五种可能取值:
1xx:指示信息–表示请求已接收,继续处理
2xx:成功–表示请求已被成功接收、理解、接受
3xx:重定向–要完成请求必须进行更进一步的操做
4xx:客户端错误–请求有语法错误或请求没法实现
5xx:服务器端错误–服务器未能实现合法的请求
常见状态代码、状态描述、说明:
200 OK //客户端请求成功 400 Bad Request //客户端请求有语法错误,不能被服务器所理解 401 Unauthorized //请求未经受权,这个状态代码必须和WWW-Authenticate报头域一块儿使用 403 Forbidden //服务器收到请求,可是拒绝提供服务 404 Not Found //请求资源不存在,eg:输入了错误的URL 500 Internal Server Error //服务器发生不可预期的错误 503 Server Unavailable //服务器当前不能处理客户端的请求,一段时间后可能恢复正常
超文本传输安全协议(英语:Hypertext Transfer Protocol Secure,缩写:HTTPS,常称为HTTP over TLS,HTTP over SSL或HTTP Secure)是一种经过计算机网络进行安全通讯的传输协议。HTTPS经由HTTP进行通讯,但利用SSL/TLS来加密数据包。HTTPS开发的主要目的,是提供对网站服务器的身份认证,保护交换数据的隐私与完整性。这个协议由网景公司(Netscape)在1994年首次提出,随后扩展到互联网上。
Http协议运行在TCP之上,明文传输,客户端与服务器端都没法验证对方的身份;Https是身披SSL(Secure Socket Layer)外壳的Http,运行于SSL()上,SSL运行于TCP之上,是添加了加密和认证机制的HTTP。两者之间存在以下不一样:
DNS是一中用于TCP/IP应用程序的分布式数据库,它提供域名到IP地址的转换。举例来讲,若是你要访问域名math.stackexchange.com,首先要经过DNS查出它的IP地址是151.101.129.69 。
详见:https://blog.csdn.net/Lammonpeter/article/details/81358387
当DNS客户机须要在程序中使用名称时,它会查询DNS服务器来解析该名称。客户机发送的每条查询信息包括三条信息:指定的DNS域名,指定的查询类型,DNS域名的指定类别。基于UDP服务,端口53. 该应用通常不直接为用户使用,而是为其余应用服务,如HTTP,SMTP等在其中须要完成主机名到IP地址的转换。
摘自:https://www.jianshu.com/p/4bb72930231b
对称密钥加密,又称私钥加密,即信息的发送方和接收方用同一个密钥去加密和解密数据。
非对称密钥加密,又称公钥加密,它须要使用一对密钥来分别完成加密和解密操做,一个公开发布,即公开密钥,另外一个由用户本身秘密保存,即私用密钥。信息发送者用公开密钥去加密,而信息接收者则用私用密钥去解密。
因为非对称加密的方式不须要发送用来解密的私钥,因此能够保证安全性;可是和对称加密比起来,它很是的慢,因此咱们仍是要用对称加密来传送消息,但对称加密所使用的密钥咱们能够经过非对称加密的方式发送出去。
数字签名必须保证明现如下三点功能:
数字签名图解:
该图只是进行了数字签名并无对报文进行加密。
数字签名过程:A用私钥SKA对明文X进行D运算签名成为密文DSKA,B用A的公钥PKA对密文DSKA进行E运算还原出明文X。
那么这个过程是如何知足报文鉴别、报文的完整性、不能否认三个特色的呢?
具备保密性的数字签名图解:
Cookie和Session都是客户端与服务器之间保持状态的解决方案,具体来讲,cookie机制采用的是在客户端保持状态的方案,而session机制采用的是在服务器端保持状态的方案。
应用场景
平常登陆一个网站,今天输入用户名密码登陆了,次日再打开不少状况下就直接打开了。这个时候用到的一个机制就是cookie。
session的一个场景是购物车,添加了商品以后客户端处能够知道添加了哪些商品,而服务器端如何判别呢,因此也须要存储一些信息,这里就用到了session。
Cookie
通俗讲,Cookie是访问某些网站之后在本地存储的一些网站相关的信息,下次再访问的时候减小一些步骤。另一个更准确的说法是:Cookies是服务器在本地机器上存储的小段文本并随每个请求发送至同一个服务器,是一种在客户端保持状态的方案。
Cookie的主要内容包括:名字,值,过时时间,路径和域。使用Fiddler抓包就能够看见,比方说咱们打开百度的某个网站能够看到Headers包括Cookie,以下:
BIDUPSID: 9D2194F1CB8D1E56272947F6B0E5D47E PSTM: 1472480791 BAIDUID: 3C64D3C3F1753134D13C33AFD2B38367:FG ispeed_lsm: 2 MCITY: -131: pgv_pvi: 3797581824 pgv_si: s9468756992 BDUSS: JhNXVoQmhPYTVENEdIUnQ5S05xcHZMMVY5QzFRNVh5SzZoV0xMVDR6RzV-bEJZSVFBQUFBJCQAAAAAAAAAAAEAAACteXsbYnRfY2hpbGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALlxKVi5cSlYZj BD_HOME: 1 H_PS_PSSID: 1423_21080_17001_21454_21408_21530_21377_21525_21193_21340 BD_UPN: 123253 sug: 3 sugstore: 0 ORIGIN: 0 bdime: 0能够看见是key, value的形式,也就是咱们说的对应着的名字,值。过时时间是能够设置的,若是不设置,则浏览器关掉就消失了,是存储在内存当中的,不然就是按照咱们设置的时间来存储在硬盘上的,当过时后自动清除,比方说咱们开机关机关闭再打开浏览器后他都会还存在,前者称之为Session cookie 又叫 transient cookie,后者称之为Persistent cookie 又叫 permenent cookie。路径和域就是对应的域名,a网站的cookie天然不能给b用。
Session
Session是存在服务器的一种用来存放用户数据的类HashTable结构。
当浏览器 第一次发送请求时,服务器自动生成了一个HashTable和一个Session ID用来惟一标识这个HashTable,并将其经过响应发送到浏览器。当浏览器第二次发送请求,会将前一次服务器响应中的Session ID放在请求中一并发送到服务器上,服务器从请求中提取出Session ID,并和保存的全部Session ID进行对比,找到这个用户对应的HashTable。
通常这个值会有一个时间限制,超时后毁掉这个值,默认是20分钟。
Session的实现方式和Cookie有必定关系。试想一下,创建一个链接就生成一个session id,那么打开几个页面就好几个了,这显然不是咱们想要的,那么该怎么区分呢?这里就用到了Cookie,咱们能够把session id存在Cookie中,而后每次访问的时候将Session id带过去就能够识别了,是否是很方便~
(3).Session 与 Cookie 的对比
实现机制:Session的实现经常依赖于Cookie机制,经过Cookie机制回传SessionID;
大小限制:Cookie有大小限制而且浏览器对每一个站点也有cookie的个数限制,Session没有大小限制,理论上只与服务器的内存大小有关;
安全性:Cookie存在安全隐患,经过拦截或本地文件找获得cookie后能够进行攻击,而Session因为保存在服务器端,相对更加安全;
服务器资源消耗:Session是保存在服务器端上会存在一段时间才会消失,若是session过多会增长服务器的压力。
存放位置:cookie数据存放在客户的浏览器上,session数据放在服务器上。
客户端浏览器经过DNS解析到www.baidu.com的IP地址220.181.27.48,经过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48,而后经过TCP进行封装数据包,输入到网络层。
在客户端的传输层,把HTTP会话请求分红报文段,添加源和目的端口,如服务器使用80端口监听客户端的请求,客户端由系统随机选择一个端口如5000,与服务器进行交换,服务器把相应的请求返回给客户端的5000端口。而后使用IP层的IP地址查找目的端。
客户端的网络层不用关系应用层或者传输层的东西,主要作的是经过查找路由表肯定如何到达服务器,期间可能通过多个路由器,这些都是由路由器来完成的工做,我不做过多的描述,无非就是经过查找路由表决定经过那个路径到达服务器。
客户端的链路层,包经过链路层发送到路由器,经过邻居协议查找给定IP地址的MAC地址,而后发送ARP请求查找目的地址,若是获得回应后就可使用ARP的请求应答交换的IP数据包如今就能够传输了,而后发送IP数据包到达服务器的地址。
物理层使用的中间设备叫作转发器。
数据链路层使用的中间设备叫作网桥或桥接器。
网络层使用的中间设备叫作路由器。
在网络层以上使用的中间设备叫作网关。
牛客网因为访问客户量的增加,原来的服务器不足以维持请求,常常发生宕机的突发状况,所以为了解决这个问题,CEO决定新增长几台服务器,那么问题是这些接入WEB服务器第一次被访问到时,不一样协议的发生顺序是下面中的(ARP -> DNS -> HTTP)。
当你给WEB服务器接上网线的时候,它会自动发送一条ARP信息,使得接入网关能找的到它;网关上会造成一条MAC地址到IP地址的映射记录。如用户在浏览器中输入域名,如本地DNS缓存中没有,必然会进行一次DNS查询,以肯定该域名的IP地址。得到DNS对应的IP地址之后,使用HTTP协议访问web服务器(不考虑TCP三次握手创建链接的阶段)。
参考文章:
《计算机网络(第七版)》 谢希仁
维基百科