谈一下你对五层网络协议体系结构的理解
- 五层网络协议从下到上依次是物理层,数据链路层,网络层,传输层,应用层;
- 物理层: 在物理层上传输的数据单位是比特,两台物理机之间的通信就是通过比特流来传输,尽可能屏蔽掉具体传输介质和物理设备地差异.使其上面地数据链路层不必考虑具体的传输介质是什么.
- 数据链路层: 数据链路层的传输单位是帧,在两个相邻的节点之间传输数据时,数据链路层把网络层交下来的IP数据报封装成帧,在两个相邻节点间的链路上传送帧,每一帧都有一定的数据和必要的控制信息,在接收方收到数据出错时要通知发送方重新发送,直到这一帧无差错的到达接收节点;
- 网络层: 网络中通信的2个计算机之间可能要经过许多结点和链路，还可能经过几个通信子网。网络层数据传输的单位是分组（Packet）。网络层的主要任务是为要传输的分组选择一条合适的路径，使发送分组能够正确无误地按照给定的目的地址找到目的主机，交付给目的主机的传输层。
- 传输层: 运输层的任务就是负责向两台主机中进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。
- 应用层: 通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。
简单说一下每一层对应的网络协议有那些?
- 数据链路层:点对点协议PPP;停止等待协议CSMA/CD
- 网络层:IP协议;ARP地址转换协议;
- 传输层:TCP传输控制协议,UDP用户数据报文协议
- 应用层:HTTP超文本传输协议;FTP文件传输协议;SMTP简单邮件传输协议;域名系统DNS
TCP和UDP的区别?
| . | TCP | UDP |
|---|---|---|
| 是否面向连接 | 面向连接 | 无连接 |
| 传输可靠性 | 可靠 | 不可靠 |
| 传输形式 | 字节流 | 数据报文段 |
| 传输效率 | 慢 | 快 |
| 所需资源 | 多 | 少 |
| 应用场景 | 要求通信数据可靠 如:文件传输,邮件传输 | 要求通信速度高 如:域名转换,直播 |
| 首部字节 | 20-60 | 8 |
- TCP提供面向连接的服务,在传输数据之前必须先建立连接,数据传输之后释放连接,由于TCP提供可靠的,面向连接的运输服务,这难以避免增加了许多开销,如确认,流量控制,等,这不仅使协议的数据单元首部增大了很多,还要占用许多处理机资源
- UDP在传送数据之前不需要建立连接,主机收到UDP报文后,不需要给出任何确认,它不提供可靠的交付,但在某一些情况下UDP确实是一种最为有效的工作方式.
TCP滑动窗口的了解?
- RTT:发送一个数据报到收到相 对应的ACK,所花费的时间
- RTO:重传时间间隔
- TCP 利用滑动窗口实现流量控制的机制。滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。
- 在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方地发送窗口的大小,即接收窗口,发送方的发送窗口取接收窗口和拥塞窗口的最小值.
- 怎么动态调整呢?主要是通过接收方设置确认报文段的窗口字段来将窗口值告诉发送方,然后发送方再调整自己的发送窗口大小
流量控制和拥塞控制区别?
- 流量控制:TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
- 拥塞控制:出现拥塞是因为对资源需求的总和大于可用资源,网络中的许多资源供应不足,网络性能变坏,网络吞吐量就会下降
- 拥塞控制就是防止过多的数据注入到网络中,是一个全局的过程,而流量控制是端到端的通信;拥塞控制是网络发送堵塞,导致发送方发送的数据迟迟到不了接收方,流量控制发送方的速率过快,导致接收方接收缓存不够,接收窗口不够,
拥塞控制的四种算法?
- 为了进行拥塞控制,TCP发送发要维持一个拥塞窗口的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
- 慢开始,就是刚开始发送数据,拥塞窗口值慢慢从一开始增大,每经过一个轮次,一个往返时延RTT,按指数增长
- 拥塞避免,当拥塞窗口值到达满开始门限,开始按"加法增大",每经过一个轮次,窗口值+1,当发生网络拥塞,窗口值降为1,继续慢开始算法,此时慢开始的门限值变为拥塞窗口的一半
- 快重传和快恢复,就是当收到3个重复的确认段,就开始执行快重传算法,直接将窗口值降为门限值.执行拥塞避免
TCP的三四握手
image
- 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用的三次握手建立连接.
- 起初,客户端A和服务器端B都处于一个关闭(Close)状态,先有客户端主动打开连接,服务器端被动打开连接
- B的TCP服务器进程首先会创建一个传输控制块TCB,准备接收A进程的连接请求,然后服务器端B就进入一个监听(Listen)状态.等待连接
- 第一次握手,A的TCP客户端进程也是首先创建传输控制块TCB,然后,在建立TCP连接时,向B发送请求报文段,这时首部中的同步位SYN=1,同时选择一个初始序号seq=x,TCP规定,SYN的报文段不能携带数据,但是要消耗掉一个序号.此时,A进入SYN-SENT(同步已发送)状态
- 第二次握手:B收到连接请求后,如果同意建立连接,则向A发送确认,在确认报文段中应把SYN位和ACK都置为1,确认号ack=x+1,同时也为自己选择一个初始序列号seq=y.这个报文段也不携带数据,但是会消耗一个序号,此时B进入到SYN-RCVD(同步收到)状态
- 第三次握手:A收到B的确认之后,还要向B发送确认,确认报文段的ACK=1,确认好ack=y+1,而自己的序列号seq=x+1,这时ACK报文段可以携带数据,但如果不携带数据则不消耗序列,这种情况下,下一个数据报文段的序号仍是seq=x+1,这时,TCP连接已经建立,A进入已建立连接状态,当B收到确认后,B也进入了已建立连接状态,这时候双方就可以进行通信了
为什么两次握手不行?
- 第一次握手有一个隐患,就是SYN包超时,A发出的一个SYN包并没有丢失,而是超时,以至于超时到连接释放之后B才收到SYN包,B收到的SYN包是失效的,他就误认为A重新发送了一个SYN包,B会再给A发送一个SYN-ACK包,如果是两次握手,这时候B认为已经建立连接了,就会一直等待A发送数.但是显然这时一个错误的确认,如果是三次握手,A实际上并没有发出连接请求,所以它不会理睬B发过来的确认,也不会向B发送确认,B由于收不到确认,连接就会中断.
TCP四次挥手过程?
image
- 四次挥手是为了终止连接
- 起初,客户端A和服务器B都是处于连接状态
- 第一次挥手:A的应用进程发出连接释放报文段,并停止发送数据,主动关闭连接,连接释放报文段FIN置为1,其序列号为u(u为上一个已经传送的数据的最后一个字节序号+1),这时A进入终止等待1状态,等待B的确认,FIN报文段不需要携带数据,但是会消耗一个序列号
- 第二次挥手:B收到连接释放报文段后,关闭连接,向A发出确认,ACK置为1,确认号ack=u+1,这个ACK报文段的序列号seq=v,然后B进入等待关闭状态,此时A到B的连接已经释放了,但是TCP仍然处于版关闭状态,A已经已经没有给B发送的数据了,但是B还可以给A发送数据,这个过程会持续一段时间,若A收到B的确认,A进入终止等待2状态,等待B发送连接释放报文段
- 第三次挥手:如果B没有向A发送的数据,B向A发送释放报文段,FIN和ACK置为1,这个FIN报文段的序列号seq=w,B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。
- 第四次挥手:A收到B的释放报文段之后,必须对此发出确认,确认报文段ACK置为1,确认号ack=w+1,序列号seq=u+1,然后进入时间等待状态.
- 这时候TCP连接还没有释放,必须经过时间等待计时器设置的时间2MSL后,A进入到关闭状态,然后撤销传输控制块结束连接,B收到确认之后直接进入关闭状态,撤销传输控制块.
为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？
- 确保由足够的时间让B收到ACK包,因为这个ACK包是可能丢失,B收不到来自A的确认包,B就会超时重传一个FIN+ACK报文段,A重传一次确认,这个时间刚搞就是2MSL,这就是2MSL的作用.
- 如果他在发出确认之后就关闭连接,刚好A给B的确认丢失了,再次由B重传过来的FIN+ACK包就无法被A收到,B就无法进入关闭状态
TCP的可靠性体现在哪里?
- 可靠指的是保证接收方进程从缓存区读出的字节流与发送方发出的字节流是一样
- 数据包校验,就是检验数据在过程中的任何变化,若出错则丢弃数据包不做出相应,超时后重新发送数据
- 对失序的数据报重排序,TCP以字节为单位进行传送数据,我们为每一个字节编一个序号,如果收到是乱序,则重排序
- 超时重传:在规定的时间内如果不能及时收到一个确认，将重发这个报文段；
- 确认机制:接收方没收到一个段后,它将发送一个确认.确认号字段为下一个他想要接收的字段序号.
- 流量控制
请你讲讲http1.0和http1.1和2.0的区别
- HTTP1.1提出了长连接HTTP 可以在一次 TCP 连接中不断发送请求。只支持发送header而不发送body
- HTTP2.0压缩了请求头,基本单位为二进制帧流,这样的数据占用空间更少,支持服务端推送,服务端HTTP请求到达后,除了返回数据之外,还推送了额外的内容给客户端,自持多路复用,并发处理多个请求
谈下你对 HTTP 长连接和短连接的理解？分别应用于哪些场景？
在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如：JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。
而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如：Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
请说明一下http和https的区别
- 首先HTTPS不是一种新的协议,它是HTTP+SSL,可以看作是一个安全版的HTTP
- SSL是为网络通信提供安全及数据完整性的一种安全协议
- HTTP使用明文进行通信,不安全,不验证通信方的身份,通信方的身份可能被伪装,无法证明报文的完整性,报文可能被纂改
- HTTPS他并不是一个新的协议,而是让HTTP先和SSL通信,再由SSL和TCP通信,也就是说HTTPS使用了隧道进行通信,加密,认证和完整性的保护
- HTTPS默认使用443端口,HTTP使用80端口
SSL的连接过程
- 首先客户端向服务器端发出加密通信请求
- 服务器端收到请求后,向客户端以证书形式回应
- 客户端收到回应后,首先验证服务器证书,如果证书不是可信机构颁布,或者证书中的域名和实际域名不一致,或者证书已经过期,就会向访问者发出警告,由其选择是否还需要继续通信
- 服务器收到客户端的第三个随机数之后,计算生成本次会话所用到的"会话密匙".向客户端发送编码改变通知和服务器握手结束通知,随后双方按照加密密匙来通信.
什么是对称加密和非对称加密？
- 对称加密,加密和解密使用同一个密匙,运算速度快,无法安全地将密匙传输给通信方
- 非对称加密,加密和解密使用不同地密匙,更安全,匀速那速度慢.
- HTTPS采用的是这两种混合的加密机制.使用非对称的密匙,来加密用于传输对称密匙
请讲一下浏览器从接收到一个URL，到最后展示出页面，经历了哪些过程。
- DNS解析:首先浏览器会根据URL,逐层查询DNS缓存,解析URL中域名所对应的IP地址,DNS缓存从近到远依次是浏览器缓存,系统缓存,路由器缓存,ips服务器缓存,根域名服务器缓存,顶级域名服务器缓存,从哪个缓存找到对应的ip,则直接返回
- TCP连接,获得ip地址和端口以后,浏览器向服务器请求建立连接,发起三次握手
- 发送HTTP请求,浏览器向服务器发送HTTP请求
- 服务器处理请求并返回HTTP报文 :服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
- 浏览器解析渲染页面浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
- 连接结束,四次挥手
GET和POST的区别
从HTTP报文上看,GET将请求信息放在URL中,请求信息和URL以问好隔开,请求信息的格式是键值对,每两个请求信息用&号隔开,POST方式将请求信息放在报文体中,想获得请求信息,必须解析报文.由于GET请求信息放在URL中,所以是有长度限制的,post没有长度限制
GET方法是幂等的,同样的请求被指向一次与连续执行多次的效果是一样的,但是POST方法不是,每次请求POST会对服务器资源进行改变
GET方式可以被缓存,被存储,get请求会保存在浏览器的浏览记录中,而post方式不行
Cookie和Session的区别?
- 因为HTTP是无状态的,在同一个连接中,两个执行成功的请求之间是没有关系的,也就意味着我们每次访问某个有登陆需求的页面的时候,都要不厌其烦地输入账号密码,引入Cookie和Session就可以解决这些问题
- Cookie是客户端地解决方案,是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。举一个栗子,当用户访问支持Cookie的网页时,用户会提供包括用户名和密码等个人信息,并且提交至服务器,当服务器向客户端返回的同时,也会发回这些个人信息,这些信息存放在HTTP响应头,当浏览器接收到响应时,浏览器会将这些信息存放在固定的位置,当再一次发送这些请求的时候,就会把相应的Cookie发送给服务器,这些信息存放在HTTP请求头里面,服务器收到后,会解析Cookie生成这些特殊信息.请记住我,其实就是Cookie,下一次登陆就不会有登陆这种繁琐的动作了.
- Session是一种服务器端的机制,服务器使用了一种类似散列表的结构来保存信息,当浏览器发送一个请求给服务器,服务器创建一个session对象,当服务器发送响应给浏览器,会把sessionid存在cookie里面,由cookie发送给浏览器,当下一次访问服务器的时候,会把cookie发给服务器,里面携带了sessionid,服务器根据sessionid找到对应的session
HTTP状态码?
状态码是由三位数组成的,其中第一位定义了响应的类别
1XX,表示请求已经接收,继续处理
2XX,表示已经被成功接收
3XX,表示完成请求需要进一步的操作,往往这一步是跟跳转相关的
4XX,客户端错误,请求有语法错误,或者请求无法实现
5XX,服务器错误
100:信息性状态码,表示到目前为止都很正常
200:成功状态码
301:表示永久性的重定向
302:临时性的重定向
400:客户端请求有语法错误.
401:请求未授权,发送的请求需要有认证信息
403:服务器收到请求,但是拒绝提供服务.
404:请求资源不存在
500:服务器发送错误
503:服务器暂时处于超负载或者停机维护中,无法处理请求
forward和redirect的区别?
- Forward 和 Redirect代表了两种请求转发方式：直接转发和间接转发。
- 直接转发方式（Forward）：客户端和浏览器只发出一次请求，Servlet、HTML、JSP或其它信息资源，由第二个信息资源响应该请求，在请求对象 request中，保存的对象对于每个信息资源是共享的。
- 间接转发方式（Redirect）：实际是两次 HTTP 请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个 URL 发出请求，从而达到转发的目的。
- 举个通俗的例子：直接转发就相当于：“A 找 B 借钱，B 说没有，B 去找 C 借，借到借不到都会把消息传递给 A”；
间接转发就相当于："A 找 B 借钱，B 说没有，让 A 去找 C 借"。