剑指Offer——知识点储备-网络基础

计算机网络

http和https的区别

• （1）http是http协议运行在tcp之上，所传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
• （2）https是http协议运行在SSL/TLS之上，SSL/TLS运行在tcp之上。所有传输的内容都经过加密。加密采用对称加密，但对称加密的秘钥用服务器方的证书进行非对称加密，此外客户端可以验证服务器端的身份，如果配置了客户端验证，服务器方也可以验证客户端的身份。
• （3）https协议需要到CA申请证书，一般免费证书很少，需要缴费;
• （4）http是超文本传输协议，信息是明文传输，https则是具有安全性的SSL加密传输协议;
• （5）http和https使用的是完全不同的链接方式，所用的端口也不一样，前者是80，后者是443;
• （6）http的链接很简单，是无状态的。

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

• （1）查询DNS,获取域名对应的ip地址；
  
  1）浏览器搜索自身的DNS缓存；
  
  2）搜索操作系统的DNS缓存；
  
  3）读取本地的HOST文件；
  
  4）发起一个DNS系统调用；
  
  A、宽带运营服务器查看本身缓存；
  
  B、运营商服务器发起一个迭代DNS解析请求；
• （2）浏览器获得域名对应的ip地址后，发起HTTP三次握手；
• （3）TCP/IP链接建立起来后，浏览器就可以向服务器发送HTTP请求;
• （4）服务器接收到这个请求，根据路径参数，经过后端的一些处理生成html页面代码返回给浏览器;
• （5）浏览器拿到完整的html页面代码开始解析和渲染，如果遇到引用外部的js,css，图片等静态资源，它们同样也是一个个的http请求，都需要经过上面的步骤。

TCP如何保证可靠传输？三次握手过程？四次挥手过程？

TCP如何保证可靠传输

（1）数据报校验;

（2）超时重传机制;

（3）应答机制;

（4）对失序数据包重排序;

（5）TCP还能提供流量控制;

TCP是什么：（通信协议）

是一种面向连接、可靠、基于字节流的传输层通信协议。

TCP的组成部分：

特别要注意的信息：

ACK:TCP协议规定，只有ACK=1时有效，也就是连接建立后所有发送的报文ACK必须为1;

SYN:在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。若对方同意建立连接，则响应的报文中使SYN=1和ACK=1.（SYN置1表示这是一个连接请求或连接接受报文）

FIN(finish)表示终结的意思，用来释放一个连接。当FIN=1时，表明此报文段的发送数据已经发送完毕，并要求释放连接。



序号：占4字节，范围（0，232-1）,共232个序号。序号增加到232-1后，下一个序号就又回到0（采用取模运算）。TCP是面向字节流的，传输的字节流每一个字节都按照顺序编号，且必须在连接建立时设置，首部中的序号字段指本报文段所发送的数据第一个字节的序号。

例如：一报文段的序号字段值是301，而携带的数据共有100字节，表明第一个字节序号是301，最后一个字节序号是400.下一个报文段的数据序号从401开始，这个301、401叫做报文段序号。

三次握手的过程

• 第一次握手：首先由Client发出请求连接即SYN=1，ACK=0(TCP规定SYN=1时不能携带数据，但要消耗一个序列号)，因此声明自己的序号是seq=x;
• 第二次握手：然后Server一直监听客户端是否发来请求，监听到客户端有请求发送，核对后进行回复确认，即SYN=1，ACK=1，seq=y, ack=x+1;
• 第三次握手：然后Client再依次进行确认，但不用SYN,这时即为ACK=1，seq=x+1, ack=y+1. 然后就建立连接;
  
  问题：为什么进行三次握手，两次确认，两次握手，一次确认不行么？
  
  问题的根源在于防止已失效的链接请求报文段又传送到server，产生错误。

什么是“已失效的链接请求报文段”

  考虑一种正常的情况:A发出链接请求，但因链接请求报文丢失而未收到确认（可能网络阻塞、断网、断电等）。于是A再重传一次链接请求，后来收到确认（网络环境变好了），建立了链接。数据传输完毕后，就释放了链接。A共发送两个链接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的链接请求。

  现假定一种异常情况，A发送的第一个链接请求报文段并没有丢失，而在某些网络结点长时间滞留，以致延误到链接释放以后的某个时间才到达B。本来这是一个早已失效的报文段，但B收到此失效的链接请求报文段后，就误认为是A又发出一次新的链接请求。于是向A发出确认报文段，同意建立连接。假设不采用三次握手，那么只要B发出确认，新的链接就建立。

  由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输链接已经建立了，并一直等待A发来数据。从而造成B的许多资源白白浪费。

  采用三次握手的办法就可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认，B由于收不到确认，就知道A并没有要求建立连接。

释放连接的过程：

  要理解四次挥手的过程，客户端A没有东西发送时，就会请求释放连接，发送一个FIN包（没有数据），此时客户端状态变成FIN_WAIT_1(A不能发数据，但可以接受数据)，服务端B接受到A那边的链接已经关闭。B会发送一个确认的包ACK,A收到B的确认后进入FIN_WAIT_2等待状态，等待B释放连接，此时B把要发的数据发给A，发完并向A请求释放连接FIN=1，A收到后回复一个确认消息ACK=1，并进入Time_wait状态，等待2msl.

  为什么等待？

  假设A回复的确认信息一发送，就断开连接，而这个确认信息在发送的过程中丢失，B在规定时间内没有收到确认，就会重传。若A有time_wait，就会再次确认信息发送。不然会出现异常关闭。

  另外B存在一个保活状态，即使A突然故障死机，那B那边的链接资源什么时候释放呢？就是保活时间到了后，B会发送探测信息，以决定是否释放连接。

Get和Post的区别

• （1）浏览器对url的长度有限制，所以get请求不能代替post请求发送大量数据（get传送数据少，post的传输数据大）；
• （2）get请求不安全（传输过程中是明文的）（post是安全的）；
• （3）get请求是幂等的（多个请求返回同一个结果）（感觉像缓存似的)；
• （4）post请求不能被缓存；
  
  在以下情况中，请使用post请求：
• 1、无法使用缓存文件（更新服务器上的文件或数据库）;
• 2、向服务器发送大量数据（post没有数据量限制）;
• 3、发送包含未知字符的用户输入时，post比get更稳定也更可靠;

TCP和UDP区别？如何改进TCP

• （1） UDP是无连接，即发送数据之前不需要建立连接；
• （2）UDP使用尽最大努力交付，即不保证可靠交付，同时也不能使用拥塞控制；
• （3）UDP是面向报文，UDP没有拥塞控制，很适合多媒体通信要求；
• （4）UDP支持一对一，一对多，多对一和多对多的交互通信；
• （5）UDP的首部开销小，只有8个字节；
• （6）TCP是面向连接的运输层协议；
• （7）每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点（一对一）；
• （8）TCP提供可靠交付的服务；
• （9）TCP提供全双工通道 （html5 websocket就是采用全双工通道）；
• （10）TCP是面向字节流的；
• （11）首部最低20个字节；

TCP加快传输效率的方法

  采取一致确认的机制。