1.五层协议
应用层:为特定应用程序提供数据传输服务,例如HTTP、DNS等,数据单位为报文。(报文是网络中交换与传输的数据单元,即站点一次性要发送的数据块,报文包含了将要发送的完整的数据信息,长短很不一致,长度不限且可变)
运输层:提供的是进程间的通用数据传输服务,由于应用层协议很多,定义通用的运输层协议就可以支持不断增多的应用层协议。运输层包括两种协议:1.传输控制协议TCP,提供面向连接、可靠的数据传输服务,数据单位为报文段2.用户数据报协议UDP,提供无连接,尽最大努力的数据传输服务,数据单位为用户数据报。TCP主要提供完整性服务,UDP主要提供及时性服务。
网络层:为主机间提供数据传输服务,而运输层协议是为主机中的进程提供服务,网络层把运输层传递下来的报文段或者用户数据报封装成分组。
数据链路层:网络层针对的还是主机之间的数据传输服务,而主机之间可以有很多链路,链路层协议就是为同一链路的主机提供服务。数据链路层把网络层传下来的分组封装成帧。
物理层:考虑的是怎样在传输媒体上传输数据比特流,而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异,使数据链路层感觉不到这些差异。
2.OSI(七层协议)
多了表示层和会话层。五层协议中将表示层和会话层的功能留给应用程序开发者处理。七层协议从高到低依次为:应用层,表示层,会话层,运输层,网络层,数据链路层,物理层。
表示层:数据压缩、加密、以及数据描述,这使得应用程序不必担心在各台主机中数据内部格式不同的问题。
会话层:建立及管理会话。
3.TCP/IP
它只有四层,相当于五层协议中数据链路层和物理层合并为网络接口层,TCP/IP体系结构不严格遵循OSI分层概念,应用层可能会直接使用IP层或者网络接口层。
4.TCP和UDP的区别
UDP和TCP的特点:用户数据报协议UDP是无连接的,尽最大可能传输,没有拥堵控制,面向报文(对用应用程序传下来的报文不合并也不拆分,只是添加UDP首部),支持一对一,一对多,多对一,多对多的交互通信。传输控制协议TCP是面向连接的,提供可靠传输,有流量和拥堵控制,面向字节流(把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块),每一条TCP连接只能是一对一的。
5.TCP三次握手和四次挥手的原因
三次握手
假设A为客户端,B为服务器端。首先B处于LISTEN(监听)状态,等待客户的连接请求。
1.A向B发送连接请求报文,SYN=1,ACK=0,选择一个初始的序号x。
2.B收到连接请求报文,如果同意连接,则向A发送连接确认报文,SYN=1,ACK=1,确认号为x+1,同时也选择一个初始的序号y。
3.A收到B的连接确认报文后,还要向B发出确认,确认号为y+1,序号为x+1。
4.B收到A的确认后,连接建立。
三次握手的原因
第三次握手是为了防止失效的连接请求到达服务器,让服务器错误打开连接。
客户端发送的连接请求如果在网络中滞留,那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间后,就会重新请求连接。但这个滞留的连接请求最后还是会到达服务器,如果不进行三次握手,那么服务器就会打开两个连接。如果有第三次握手,客户端会忽略服务器之后发送的对滞留连接请求的连接确认,不进行第三次握手,因此就无法再次打开连接。
四次挥手
1.A发送连接释放报文,FIN=1。
2.B收到之后发送确认,此时TCP属于半关闭状态,B能向A发送数据,但是A不能向B发送数据。
3.当B不再需要连接时,发送连接释放报文,FIN=1。
4.A收到后发出确认,进入TIME-WAIT状态,等待2MSL(最大报文存活时间)后释放连接。
5.B收到A的确认后释放连接。
四次挥手的原因:
客户端发送了FIN连接释放报文之后,服务器收到了这个报文,就进入了CLOSE-WAIT状态,这个状态是为了让服务器发送还未传送完毕的数据,传送完毕后,服务器会发送FIN连接释放报文。
TIME-WAIT:客户端收到服务器端的FIN报文后进入此状态,此时并不是直接进入CLOSED状态,还需要等待一个时间计时器设置的时间2MSL,这么做有两个理由:1.确保最后一个确认报文能够到达,如果B没收到A发送来的确认报文,则会重新发送连接释放请求报文,A等待一段时间就是为了处理这种情况的发生。2.等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失,使得下一次新连接不会出现旧的连接请求报文。
6.在浏览器输入www.baidu.com后执行的全部过程
- DNS解析
- TCP连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 浏览器解析渲染页面
- 连接结束
主要涉及应用层:DNS,HTTP,传输层:TCP,网络层:IP和路由选择协议:RIP,OSPF(内部网关协议),BGP(外部网关协议)和数据链路层:ARP。
1、在应用层 客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48,
(1)首先会在浏览器缓存中去查询,之前每浏览一个网站,浏览器都会在缓存中存有域名与ip地址的映射关系。不过缓存失效的时间不由浏览器决定,而由操作系统决定。
(2)浏览器缓存中查询不到后,之后会在系统缓存中查询,由浏览器发起一个系统调用,查询系统缓存中的数据。
(3)系统缓存中也查询不到后,将会去路由器缓存中查找。
(4)路由器缓存中也找不到的话,将会从本地DNS服务器的缓存中查找,本地服务器即用户自己配置的DNS服务器。
(5)如果本地的DNS服务器也找不到的话,本地DNS将会发送请求至根域名服务器,根域名服务器中没有相关缓存数据的时候,就会返回com顶级域名服务器的地址。然后本地DNS服务器再发送请求至com顶级域名服务器,com顶级域名服务器中查询不到的话,就会返回baidu权威服务器的地址,然后本地DNS服务器再发送请求至baidu权威服务器,baidu权威服务器就会返回www主机地址。(这是一种迭代的过程,还有一种递归的过程。即local至根域名,根域名不直接返回com地址,而是发送请求至com,com发送请求至baidu,baidu发送请求至www,www再返回给baidu,baidu返回给com,com再返回给local)至此,整个DNS查询步骤结束,现在浏览器拿到了域名对应的ip地址。
2、之后就是通过这个IP地址找到客户端到服务器的路径。在应用层,客户端浏览器发起一个HTTP会话到220.161.27.48,通过TCP进行封装数据包,输入到网络层。
3、在客户端的传输层(添加TCP头),把HTTP会话请求分成报文段,添加源和目的端口,如服务器使用80端口监听客户端的请求,客户端由系统随机选择一个端口如5000,与服务器进行交换,服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。
4、客户端的网络层(添加IP头)不用关系应用层或者传输层的东西,主要做的是通过查找路由表确定如何到达服务器,期间可能经过多个路由器,这些都是由路由器来完成的工作,我不作过多的描述,无非就是通过查找路由表决定通过那个路径到达服务器。
5、客户端的链路层(添加MAC头),包通过链路层发送到路由器,通过邻居协议查找给定IP地址的MAC地址,然后发送ARP请求查找目的地址,如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了,然后发送IP数据包到达服务器的地址。
6、 服务器接收到这个请求,并根据路径参数映射到特定的请求处理器进行处理,并将处理结果及相应的视图返回给浏览器;
7. 浏览器解析并渲染视图,若遇到对js文件、css文件及图片等静态资源的引用,则重复上述步骤并向服务器请求这些资源;
8. 浏览器根据其请求到的资源、数据渲染页面,最终向用户呈现一个完整的页面。
浏览器通过Ajax(Asynchronous Javascript And XML 异步 JavaScript 和 XML)
9、在传统的web应用,用户每发一次请求,用户的动作就会被阻塞,即在服务器返回响应之前,用户不可以进行其他的操作,只能等待响应。然后服务器会响应一个完整的html页面,浏览器再次进行渲染。哪怕是一个很小的一个请求,都会阻塞用户动作,以及刷新整个页面,极大地浪费了用户的时间和网络的带宽,也增加了服务器的压力。
Ajax出现之后,通过此技术发起的http请求,将不会阻塞用户的动作,服务器响应之后,页面会进行一个局部的刷新,也就是不会刷新整个页面,极大提高了页面加载与服务器处理的效率。当然Ajax也要自身的缺点,暴露了浏览器和服务器通信的具体逻辑,容易造成漏洞攻击。此外,Ajax没有后退机制,在一定程度上,用户的体验感降低。
百度界面显示出来后,百度又利用了ajax去请求我之前的搜索关键词,然后利用js填充到搜索框的下拉列表中,返回的数据如下
7.TCP协议如何保证可靠传输
- 应用数据被分割成 TCP 认为最适合发送的数据块。
- TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
- 校验和: TCP 将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。
- TCP 的接收端会丢弃重复的数据。
- 流量控制: TCP 连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 (TCP 利用滑动窗口实现流量控制)
- 拥塞控制: 当网络拥塞时,减少数据的发送。
- ARQ协议: 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
- 超时重传: 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
8.ARQ协议、滑动窗口和流量控制、拥塞控制
ARQ协议
自动重传请求(Automatic Repeat-reQuest,ARQ)是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。
停止等待ARQ协议
- 停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认(回复ACK)。如果过了一段时间(超时时间后),还是没有收到 ACK 确认,说明没有发送成功,需要重新发送,直到收到确认后再发下一个分组;
- 在停止等待协议中,若接收方收到重复分组,就丢弃该分组,但同时还要发送确认;
优点: 简单
缺点: 信道利用率低,等待时间长
1) 无差错情况:
发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。
2) 出现差错情况(超时重传):
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组,就丢弃该分组,但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口,凡位于发送窗口内的分组可连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组位置的所有分组都已经正确收到了。
3) 确认丢失和确认迟到
- 确认丢失 :确认消息在传输过程丢失。当A发送M1消息,B收到后,B向A发送了一个M1确认消息,但却在传输过程中丢失。而A并不知道,在超时计时过后,A重传M1消息,B再次收到该消息后采取以下两点措施:1. 丢弃这个重复的M1消息,不向上层交付。 2. 向A发送确认消息。(不会认为已经发送过了,就不再发送。A能重传,就证明B的确认消息丢失)。
- 确认迟到 :确认消息在传输过程中迟到。A发送M1消息,B收到并发送确认。在超时时间内没有收到确认消息,A重传M1消息,B仍然收到并继续发送确认消息(B收到了2份M1)。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会,A收到了B第一次发送的对M1的确认消息(A也收到了2份确认消息)。处理如下:1. A收到重复的确认后,直接丢弃。2. B收到重复的M1后,也直接丢弃重复的M1。
连续ARQ协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累计确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。
优点: 信道利用率高,容易实现,即使确认丢失,也不必重传。
缺点: 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如:发送方发送了 5条 消息,中间第三条丢失(3号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传一次。这也叫 Go-Back-N(回退 N),表示需要退回来重传已经发送过的 N 个消息。
滑动窗口和流量控制
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
拥塞控制
在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。
为了进行拥塞控制,TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP的拥塞控制采用了四种算法,即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。
- 慢开始: 慢开始算法的思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。经验表明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1,每经过一个传播轮次,cwnd加倍。
- 拥塞避免: 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大,即每经过一个往返时间RTT就把发送放的cwnd加1.
- 快重传与快恢复: 在 TCP/IP 中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。有了 FRR,就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时,快速重传和恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作。
9.状态码
10.http长连接、短连接
在HTTP/1.0中默认使用短连接。也就是说,客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源(如JavaScript文件、图像文件、CSS文件等),每遇到这样一个Web资源,浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头加入这行代码:
Connection:keep-alive
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
11.http和https的区别
- 端口 :HTTP的URL由“http://”起始且默认使用端口80,而HTTPS的URL由“https://”起始且默认使用端口443。
- 安全性和资源消耗: HTTP协议运行在TCP之上,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议,SSL/TLS 运行在TCP之上。所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密。所以说,HTTP 安全性没有 HTTPS高,但是 HTTPS 比HTTP耗费更多服务器资源。
- 对称加密:密钥只有一个,加密解密为同一个密码,且加解密速度快,典型的对称加密算法有DES、AES等;
- 非对称加密:密钥成对出现(且根据公钥无法推知私钥,根据私钥也无法推知公钥),加密解密使用不同密钥(公钥加密需要私钥解密,私钥加密需要公钥解密),相对对称加密速度较慢,典型的非对称加密算法有RSA、DSA等。
12.http2.0新特性
新的二进制格式(Binary Format),HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮。
多路复用(MultiPlexing),即连接共享,即每一个request都是是用作连接共享机制的。一个request对应一个id,这样一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
header压缩,如上文中所言,对前面提到过HTTP1.x的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。
服务端推送(server push),同SPDY一样,HTTP2.0也具有server push功能。
13.URI和URL
- URI(Uniform Resource Identifier) 是统一资源标志符,可以唯一标识一个资源。
- URL(Uniform Resource Location) 是统一资源定位符,可以提供该资源的路径。它是一种具体的 URI,即 URL 可以用来标识一个资源,而且还指明了如何 locate 这个资源
14.get和post方法的区别
1. Get是不安全的,因为在传输过程,数据被放在请求的URL中;Post的所有操作对用户来说都是不可见的。 2. Get传送的数据量较小,这主要是因为受URL长度限制;Post传送的数据量较大,一般被默认为不受限制。 3. Get限制Form表单的数据集的值必须为ASCII字符;而Post支持整个ISO10646字符集。 4. Get执行效率却比Post方法好。Get是form提交的默认方法。
15.路由器和交换机的区别
1、工作层次不同:交换机比路由器更简单,路由器比交换器能获取更多信息
交换机工作在数据链路层,而路由器工作在网络层
2、数据转发所依据的对象不同
交换机的数据转发依据是利用物理地址或者说MAC地址来确定转发数据的目的地址
而路由器是依据ip地址进行工作的
3.传统的交换机只能分割冲突域,不能分割广播域;而路由器可以分割广播域
16.cookie和session
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式,但是两者的应用场景不太一样。
Cookie 一般用来保存用户信息 比如①我们在 Cookie 中保存已经登录过得用户信息,下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了;②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了,这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中,下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑,重新登录一般要将 Token 重写);③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
Cookie 数据保存在客户端(浏览器端),Session 数据保存在服务器端。
Cookie 存储在客户端中,而Session存储在服务器上,相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息,不要直接写入 Cookie 中,最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
17.icmp协议、rpc协议、dns协议、arp协议
ICMP协议
它是TCP/IP协议族的一个子协议,用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据,但是对于用户数据的传递起着重要的作用。
RPC协议
首先了解什么叫RPC,为什么要RPC,RPC是指远程过程调用,也就是说两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。
首先,要解决通讯的问题,主要是通过在客户端和服务器之间建立TCP连接,远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接,调用结束后就断掉,也可以是长连接,多个远程过程调用共享同一个连接。
- 第二,要解决寻址的问题,也就是说,A服务器上的应用怎么告诉底层的RPC框架,如何连接到B服务器(如主机或IP地址)以及特定的端口,方法的名称名称是什么,这样才能完成调用。比如基于Web服务协议栈的RPC,就要提供一个endpoint URI,或者是从UDDI服务上查找。如果是RMI调用的话,还需要一个RMI Registry来注册服务的地址。
- 第三,当A服务器上的应用发起远程过程调用时,方法的参数需要通过底层的网络协议如TCP传递到B服务器,由于网络协议是基于二进制的,内存中的参数的值要序列化成二进制的形式,也就是序列化(Serialize)或编组(marshal),通过寻址和传输将序列化的二进制发送给B服务器。
- 第四,B服务器收到请求后,需要对参数进行反序列化(序列化的逆操作),恢复为内存中的表达方式,然后找到对应的方法(寻址的一部分)进行本地调用,然后得到返回值。
- 第五,返回值还要发送回服务器A上的应用,也要经过序列化的方式发送,服务器A接到后,再反序列化,恢复为内存中的表达方式,交给A服务器上的应用
DNS协议和ARP协议
ARP工作在数据链路层
DNS是在网络层的,arp是地址解释协议;dns是域名服务;
前者将IP解释为MAC地址,
后者将域名解释为IP地址。
18.MAC地址和IP地址
IP地址描述的是路途的起点和终点,MAC地址描述的是路途中每一个区间的起点和终点。