网络基础

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的链接很简单，是无状态的。
对称加密（DES,3DES,AES）：加密和解密使用的同一个秘钥。
非对称加密(RSA,DSA)：使用公钥和私钥。
私钥用来解密和签名，是给自己用的。
公钥由本人公开，用来加密和验证签名，是给别人用的。
当该用户发送文件时，使用私钥签名，别人用他给的公钥验证签名，可以保证该信息是由他发送的。当该用户接收文件时，别人用他的公钥加密，他用私钥解密，可以保证该信息只能由他接收到。

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

1. 查询DNS,获取域名对应的ip地址；
   1）浏览器搜索自身的DNS缓存；
   2）搜索操作系统的DNS缓存；
   3）读取本地的HOST文件；
   4）发起一个DNS系统调用；
   A、宽带运营服务器查看本身缓存；
   B、运营商服务器发起一个迭代DNS解析请求；
2. 浏览器获得域名对应的ip地址后，发起TCP三次握手；
3. TCP/IP链接建立起来后，浏览器就可以向服务器发送HTTP请求;(请求行：【请求的种类（get/post/put/delete），请求资源的路径，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加快传输效率的方法

采取一致确认的机制。