计算机网络

http和https?

   http是一个超文本传输协议，用于在浏览器和服务器之间传递信息，是以明文的方式发送内容的，它不提供任何方式的数据加密，所以不是安全的。https就是带有ssl的http，它的出现就是为了解决http的安全问题的。

 

http包含什么？

    请求行  请求头    请求数据    响应行   响应头   响应体   

    请求行由方法字段，url，http协议版本组成：get /baidu.html http/1.1

 

HTTP和HTTPS的区别

http协议运行在tcp上，明文传输，客户端与服务端都无法验证对方的身份

https是带有SSl的http，运行于ssl上，ssl运行于tcp上，是添加了加密和认证机制的http。

http的连接很简单，是无状态的，而https协议由ssl+http协议构建，可进行加密，身份验证和网络协议

端口不同：http用的80，https用的443

资源消耗：https由于加密解密会消耗更多的cpu和内存资源

开销：https需要证书，证书需要买

 

HTTP原理？

  浏览器通过tcp建立与服务器之间的连接，建立连接后发送请求给服务器，服务器接收到请求后，返回相应的响应信息（状态行，包括协议版本号，成功或错误的代码以及可能的内容）

 

HTTPS的原理？

   首先客户端发起https请求，服务端返回包含公钥的证书，客户端对证书进行验证，抽取公钥，再产生一个随机数并使用公钥进行加密，然后将加密后的信息发送给服务端，服务端根据私钥对随机数进行解密，服务端通过客户端传过来的随机数构造对称加密算法，对结果进行加密然后返回给客户端

  注：https中只有服务端保存了私钥

 

HTTPS的缺点？

    1）https协议握手阶段比较耗时，会使页面的加载时间延长接近百分之50,

    2）https连接缓存没有http高效

    3）ssl证书也需要购买

 

http的缓存机制？

   http根据是否需要向服务器重新发送请求分为了强制缓存和对比缓存

   强制缓存：

           1.在已缓存数据的情况下，基于强制缓存请求数据的流程是这样的：

                  1）客户端会先向缓存数据库请求数据，缓存命中的话，直接返回给客户端

                  2）缓存没有命中的话，缓存数据库会告诉客户端缓存失效，然后客户端再向服务器请求数据，服务器会返回数据和缓存规则，然后客户端将数据和缓存规则存入缓存数据库中

   对比缓存：

             1.在已缓存数据的情况下，基于对比缓存是这样的：

                  1）客户端向缓存数据库获取缓存数据的标识，然后缓存数据库将标识返回给客户端，客户端再去向服务器请求验证数据是否失效，没有失效的话再去向缓存数据库获取数据

                 2）失效的话服务器会返回最新数据和缓存规则给客户端，客户端再将数据和缓存规则存入缓存数据库中

 

浏览器的强制缓存优先级高于对比缓存，当缓存生效时，直接使用缓存，不再执行对比缓存

  所以，当数据更新后，浏览器怎么知道从服务器中获取数据而不是从缓存中获取数据就很简单了：

              当浏览器再次请求数据时，客户端将缓存标识发送给服务器，服务器根据缓存标识判断是否失效，如果没有失效，那么会返回304给客户端，这个时候客户端直接用缓存数据库中的缓存，如果失效，再向服务器取数据和缓存规则然后再存入缓存数据库中

 

osi七层模型？

 

 

四层模型：应用层 传输层 网络层 数据链路层

                   

 

2.对称加密与非对称加密

   对称密钥是加密和解密用的同一个密钥，非对称密钥使用的是公钥和私钥，公钥可以随意发布，私钥只有自己知道，由于非对称加密不需要发送用来解密的密钥，所以可以保证安全性，但是比对称密钥慢，所以我们还是用对称加密来传送消息，但是对称加密使用的密钥可以通过非对称加密的方式发送出去

 

3.三次握手

   第一次握手：客户端将带有syn（syn=j）的数据包发送到服务器，自己进入syn_sent状态，等待服务器确认。syn：同步序列编号

   第二次握手：服务器收到数据包后，也就是设置ack为j+1，然后自己的syn为k，再将syn和ack发送到客户端

   第三次握手：客户端收到服务器的syn和ack后，确认服务端的发送过来的ack后，再设置ack为k+1，然后将ack发送给服务端，之后两者都进入establish状态

   

   为什么3次？而不是两次握手或者四次？

         主要有3个原因：1.防止旧的重复连接建立   2.可以同步双方的初始化序列号    3.可以避免资源浪费

         1）假如是三次握手，这时候由于网络的原因导致旧的syn报文比新的先到达，此时服务端返回syn+ack给客户端，客户端就能判断这是否是一个历史连接，如果是的话就会发送rst给服务端终止这次连接。而如果是两次握手，就不能判断当前连接是否是历史连接（因为第三次握手假如是历史连接发送的是rst报文，而不是历史连接发送的就是ack报文）

       2）tcp双方都必须维护一个序列号，它可以去除重复的数据，根据序列号按顺序接收，标识发出的数据包哪些已经被对方接收到。而两次握手只能保证一方的初始化序列号被对方成功接收，无法保证双方的初始化序列号都被接收，而服务端可以将ack和syn一起发送给客户端，因此就不需要四次握手而是只需要三次握手了

      3）如果只有两次握手，当客户端的syn在网络中阻塞时，就收不到服务端的ack报文，就会重新发送syn，由于没有三次握手，服务端就不清楚客户端是否收到了自己发出ack，所以每收到一个syn都会先主动建立一个连接，就会造成资源浪费

      

 

为什么要回传syn？

    接收端传回发送端发送的syn是为了告诉发送端接收到的信息就是发送端发送的信息

传了syn为什么还要传送ACK？

  双方通信正常是指的双方互相发送消息都正常，传回syn只是表示发送端到接收端的通道没问题，但是接收端到发送端的通道还需要ACK信号来验证

 

 

 

4.四次挥手（断开连接）

1）第一次挥手：Client发送一个FIN，用来关闭Client和Server的数据传输，Client进入FIN_WAIT_1状态

2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1,Server进入CLOSE_WAIT状态，客户端收到ack后进入FIN_WAIT_2状态，此时TCP连接处于半关闭状态

3）第三次挥手：Server发送一个FIN，用来关闭Server和Client的数据传送，Server进入LAST_ACK状态

4）第四次挥手：Client收到FIN后，接着发送一个ACK给Server，确认序号为收到序号+1，进入TIME_WAIT状态，Server接收到ack后进入CLose状态，在2msl时间后，客户端也进入close状态，完成四次挥手

 

注意，只有主动关闭连接的，才有time_wait状态

 

为什么是四次挥手？

    因为关闭连接时，客户端向服务端发送fin，仅仅表示客户端不再发送数据但是还能接受数据，服务端收到客户端的fin后，会先回复一个ack报文，这个时候服务端可能还有数据需要发送给客户端，等到服务端不再发送数据时才发送一个fin给客户端来请求关闭服务端和客户端的连接。所以服务端的fin和ack是分别发送的，也就多了一次挥手

 

为什么不是三次挥手？

   因为假如是三次挥手的话，那么服务端就得把fin和ack一起发送到客户端，而客户端接收到了就会关闭连接，这个时候可能服务端还有没有发送的数据。

 

 

5.Get与Post的区别

1）Get一般从服务器上获取资源，Post一般更新服务器上的资源

2）Get请求的数据附在Url之后，放在报文的请求头中，以?分割url和传输数据，参数之间以&连接，Post会把数据放在报文的请求体中。

3）Post安全性更高，因为Get会把数据暴露在url上

4）Get请求的长度受限于url长度的限制，发送的数据量较小

 

6.TCP与UDP的区别？

1）tcp是面向连接的，udp是无连接的：tcp在传输数据之前必须先建立好连接，而且是一对一的连接，而udp可以一个主机同时向多个主机发送消息

2）tcp是可靠的，udp是不可靠的：tcp要通过三次握手四次挥手来建立和断开乱接，并且在传输过程中还有流量控制，拥塞控制，失败重传等机制，而udp是尽最大努力交付，不保证可靠交付数据

3）tcp只支持点对点通信，udp支持一对一，一对多，多对一，多对对的通信方式

4）tcp是面向字节流的，udp是面向报文的：面向字节流的原因是因为tcp连接是可靠连接，所以可以多次发送，然后接收方一次接收，而udp无连接，所以必须发送方一次发送，接收方一次接收，因为udp连接并不能保证发送数据的都是同一个客户端

6）tcp的首部开销更大，有20个字节，而udp首部8个字节并且固定不变

7）tcp由于要进行三次握手四次挥手等操作，所以tcp的传输速度比udp慢

 

7，从输入网址到获得页面的过程

1）浏览器查询dns，获取域名对应的ip地址

2）浏览器获得域名对应的ip地址以后，发起三次握手

3）tcp/ip连接建立后，浏览器向服务器发送http请求

4）服务器接收到这个请求后，返回数据给浏览器

5）浏览器根据请求到的资源进行渲染

 

8.Session，Cookie

   cookie是服务器存放在本地浏览器上的一小段文本，会随着每一个请求发送到同一个服务器，是客户端保持状态的方案。可以设置过期时间，不设置的话关掉浏览器就消失，这个时候是存储在内存上的，而设置了过期时间的话就存储在磁盘上了，过期后自动删除

    session是存放在服务器上的一种用来存放用户数据的类HashTable结构。当浏览器第一次发送请求时，服务器会自动生成session和sessionid，并将sessionid通过响应发送给浏览器，当浏览器第二次发送请求时会带上sessionid，然后服务器从请求中取出sessionid，并和保存的所有sessionid对比，然后找到用户的session。session对象中的变量不会丢失而是在整个会话中一直存在。session的实现方式依赖于cookie，它的sessionid是存放在cookie中的，每次访问的时候将sessionid带过去就可以识别了

    区别：

          1.session能够存储任意对象，cookie只能存储string对象

          2.cookie在客户端，可以伪造，所以不安全，session在服务端，更加的安全

          3.session过多会消耗服务器资源

 

 

ICMP？

互联网控制消息协议，承担网络层通信差错检测和报告机制的协议，ping命令就是基于ICMP协议来验证网络层连通性的工具

 

Tcp协议？

tcp协议能够对自己提供的连接实施控制，是一种可靠的传输层协议，传输层协议最本质的任务是把网络层协议提供的终端之间的通信服务，扩展到终端系统中运行的应用程序之间。也就是说在为应用进程建立通信之前，tcp需要建立传输数据所需的连接，一旦tcp连接建立成功，应用层之间就可以通过这条tcp连接相互发送上层数据

 

tcp通过什么方式来提供可靠传播的？

1.对数据进行分割和重组：tcp能够将数据分割为适当大小进行传输

2.确保数据按顺序传输：会为自己发出的数据表明序列号

3.支持失败重传

4.能够进行流量控制：通过滑动窗口实现

5.拥塞控制

 

tcp头部：

1.源端口：源设备上应用进程所使用的tcp端口号

2.目的端口：指明目的设备上应用进程锁使用的tcp端口号

3.序列号：表示发送数据的位置（保证报文按顺序到达，保证可靠性，保证效率）

4.确认号：确认已收到的数据

5.头部长度：标识tcp头部的总长度

6.窗口长度：接收多少字节的数据

 

网络各层的功能？

1）传输层：建立端口到端口的通信

2）网络层：建立主机到主机的通信

3）数据链路层：两台主机之间的数据传输，总是在一段一段的链路上传输的，这就需要专门的链路层协议。在两个节点间传送数据时，数据链路层将网络层交下来的ip数据包组装成帧，在两个节点的链路上传送帧，每一帧包括数据和必要的控制信息

4）物理层：把两台计算机连接起来，然后在计算机之间传输

 

http1.1和1.0的区别？

1）缓存处理：1.1引入了更多的控制缓存策略

2）带宽优化以及网络连接的使用：1.0中存在带宽浪费的现象，1.1在请求头中引入了range头域，允许只请求资源的某个部分

3）错误通知的管理：1.1中新增了25个错误状态响应码

4）host头处理：1.1的请求消息和响应消息都应支持host头域，且请求消息中如果没有host头域会报400错误

5）长连接：1.1支持长连接和请求的流水线处理，在一个tcp连接上可以传送多个http请求和响应，减少了建立和关闭连接的消耗和延迟

 

tcp1.0,1.1,2.0的区别？

   1.1是默认长连接的，1.0需要主动建立，1.1支持只发送header信息而不用发送请求体，可以节约带宽，1.1还支持host域

   2.0支持多路复用（即一个连接处理并发请求多次，如果数据并没有准备好，用户线程还可以去做其他事而不会被阻塞在这里），并且支持数据压缩（用的hpack算法，传输速度更快），支持服务器推送，服务端会把相关的客户端需要的数据一并传输过去（比如静态文件）
 

 

 

什么是阻塞，什么是非阻塞？

阻塞：当某个事件或者任务在执行过程中，发出一个请求操作，但由于该请求操作需要的条件不满足，它就会一直等待

非阻塞：当某个事件或者任务在执行过程中，发出一个请求操作，但由于条件不满足，它会立即回一个消息而不会等待

 

 

 

9.状态码

200：请求成功

206：部分请求成功

301：永久重定向

302：临时重定向

400：客户端请求有语法错误

401：请求未经授权

403：服务端收到请求，但是拒绝提供服务

404：url错误

500：服务端发生错误

503：服务端当前不能处理请求，一段时间后可能恢复正常

502：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应

504：作为网关或者代理工作的服务器尝试执行请求时，没有及时从上游服务器或辅助服务器收到响应

 

time_wait（2MSL）?

     第一，为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。 
    第二，使两个方向上的数据包都被丢弃，原来的数据包都从网络中消息，这样的话下一次连接出现的数据包就一定是新连接产生的

产生大量time_wait的原因及危害？

  如果某些服务（ftp/pop）是服务端在收到客户端的quit命令后主动关闭连接，这就会造成容易出现大量time_wait状态的连接，当客户端程序忘记关闭连接时也容易出现time_wait。但是大量的time_wait也不好，因为它占用了资源导致不能创建更多的socket，socket的数量是有限的，最多65535，并且过多的time_wait也会占用内存，一个占4kb

   解决方法：调整time_wait的超时时间（优化到30s）
 

 

tcp的流量控制和拥塞控制？

   tcp流量控制（滑动窗口）：

          流量控制就是让发送方的发送速率不要太快，要让接收方来得及接受，原理是通过确认报文中窗口字段来控制发送方的发送速率，发送方的发送窗口大小不能超过接收方给出的窗口大小。

          这个时候可能接收方向发送方发送了零窗口的报文段后，接收方又有了新的存储空间，而接收方向发送方发送非零窗口的报文段出现了丢失，发送方的发送窗口会一直为零导致死锁，为了解决这个问题，为每个连接设置了持续计时器，只要接收方一收到零窗口通知，就会启动持续计时器，如果时间到期，就会发送一个零窗口探测报文段，这个时候对方要确认窗口值，如果窗口仍为0，则收到报文段的一方重置持续计时器

   tcp的拥塞控制：

         为了防止过多的数据注入到网络中，为了控制发送方的速率，但是流量控制是为了让接收方来得及接收，而拥塞控制是为了降低整个网络的拥塞程度（是全局性的）

        做法：发送方让自己的发送窗口等于拥塞窗口，拥塞窗口的大小取决于网络的拥塞程度，并且动态变化

                   1.数据是单向传送的，对方只传送确认报文

                   2.接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度决定

     

     慢开始和拥塞避免：发送的最初执行慢开始，令cwnd=1，也就是发送方只能发送1个报文段，收到确认后，cwnd加倍，当cwnd大于ssthresh（慢开始门限）时，改为拥塞避免算法（也就是每经过一个往返cwnd加1），当cwnd=ssthresh时，既可以采用慢开始，也可以采用拥塞避免算法，当cwnd小于ssthresh时，使用慢开始算法，当网络超时时，将ssthresh设置为cwnd/2，同时设置拥塞窗口cwnd=1，开始慢开始算法

    快重传：快重传要求接收方在接收到一个失序的报文段后就立即发送重复确认而不是等到自己发送数据时才确认。快重传规定发送方只要一连收到三个重复确认就应当立即重传对方未收到的报文段，而不是等到重传计时时间到期。

   快恢复：当发送方连续收到3个重复确认时，执行乘法减小算法，把ssthresh门限减半，但是此时把cwnd设置为ssthresh的大小，然后执行的是拥塞避免算法
 

 

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

 

介绍tcp/ip   http协议？

   ip协议：因特网协议，规定了数据传输时的基本单元和格式，还定义了数据包的递交方法和路由选择

   tcp协议：能够对自己提供的连接实施控制，是一种可靠的传输层协议，tcp协议建立了首次传输数据所需的连接，一旦tcp连接建立成功，应用层之间就可以通过这条tcp连接相互发送数据，它提供了可靠的面向对象的数据流传输服务

   http协议：即超文本传输协议，是建立在tcp协议上的一种应用层协议，最显著的特点是客户端发送的每次请求都需要服务器返回响应
 

 

tcp三次握手第三次的ack丢失会怎么办（第二次握手没有回复）？

    服务端：根据tcp的超时重传机制，等待3秒，6秒，12秒后重新发送ack包给客户端，发送次数可以修改，默认为5，如果指定次数后依然没有收到，那么服务端关闭这个连接

    客户端：服务端将响应rst包，这样客户端就能感觉到服务端的错误

 

tcp的缺陷？

   由于传递数据需要三次握手来建立连接，所以速度慢，并且由于tcp的确认机制和三次握手机制，可能会收到dos攻击（通过发送大量的半连接请求也就是syn洪水攻击，消耗cpu和内存资源：客户端短时间伪造大量不存在的ip地址，向服务器不断发送syn包等待客户的确认，但是ip地址实际上不存在，所以服务器需要不断地重发）

 

 

tcp状态转换过程？

  三次握手：首先处于close状态，然后服务器进入listen状态开始监听，接着客户端发送syn给服务器，客户端进入syn_sent状态，服务端收到syn后，返回ack给客户端，自己进入syn_recv状态，客户端收到ack后，再发送ack给服务端，自己进入establish状态，服务端接收到ack后，自己也进入establish状态

   四次挥手：客户端发送fin给服务端，自己进入fin_wait_1状态，客户端收到服务端的ack后，再进入fin_wait_2状态，收到了服务端的fin后，客户端发送ack给服务端，自己进入time_wait状态

time_wait的原因：为了使客户端最后发送的ack能够到达服务端，还有一个目的就是让在网络中的报文都消失掉
 

 

tcp流模式与udp报文模式的区别？

  tcp是基于字节流的，当发送端发送数据时，接收端可以不必一次接收完，而是分几次接收，也可以发送方发送几次，然后接收端一次接收完，但是发送端发送的数据量不能大于对方的流量控制

   udp是发送一次，接收端就必须接收一次，如果缓冲区小于报文长度，那么多出的部分会被抛弃

   不同的原因是因为：tcp是面向连接的，在连接持续的过程中，服务端收到的数据都是由同一台主机发出的，这个时候就不存在数据劫持问题，只要保证数据有序到达就行。

                                   而udp是无连接的，只要知道接收端的ip和端口号，任何主机都能向接收方发送数据，所以是发送一次就接收一次