http常见总结

http常见总结

网络综述

tcp/ip协议广义可以认为是ip协议通信过程中，使用到的协议族的统称。

tcp/ip协议族可以分为以下4层。

应用层：决定向用户提供应用服务时通信的活动。FTP，dns，http

传输层：提供两台计算机之间的数据传输。tcp和udp

网络层：处理流动的数据包，选择传输路线。路由。

链路层：处理连接的硬件部分及物理部分。

客户端发出想看web页面的请求，tcp接到http报文分割，打上标记序号端口号再给网络层，网络层增加Mac地址再给链路层（每通过一层则增加首部）。然后传到服务端再拆分组合起来。

ip地址指明了节点被分配的地址。Mac地址指网卡所属的固定地址。ip地址可以和Mac地址进行配对。ip地址可变换，但Mac地址基本不改变。

tcp

三次握手？为什么不是两次

【一个双向建立连接的过程】

TCP在传输之前会进行三次沟通，一般称为“三次握手”，传完数据断开的时候要进行四次沟通，一般称为“四次挥手”。

 1）序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。  

（2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。  

（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：  
（A）URG：紧急指针（urgent pointer）有效。  
（B）ACK：确认序号有效。  
（C）PSH：接收方应该尽快将这个报文交给应用层。 
（D）RST：重置连接。  
（E）SYN：发起一个新连接。  
（F）FIN：释放一个连接。  
需要注意的是：  
（1）不要将确认序号ack与标志位中的ACK搞混了。  （2）确认方ack=发起方seq+1，两端配对。

三次握手：

A seq x SYN=1,ACK=0

B seq y(自己的序号) ack=x+1(准备接收A的) SYN=1;ACK=1

A seq (x+1) ack y+1（准备接收B的）ACK=1

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，

 收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。

A FIN=1 传送最后数据，FIN_wait_1 seq=x

B 收到FIN后 发ack=x+1 seq=v

B 发FIN=1 传输完毕 seq=w ack=x+1

A seq=x+1 ack=w+1

tcp&udp区别

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

	TCP	UDP
是否连接	面向连接	面向非连接
传输可靠性	可靠	不可靠
应用场合	传输大量的数据，对可靠性要求较高的场合	传送少量数据、对可靠性要求不高的场景
速度	慢	快
	.TCP保证数据正确性，UDP可能丢包，	TCP保证数据顺序，UDP不保证。
应用	HTTP,HTTPS,FTP等传输文件的协议，POP,SMTP等邮件的传输协议	视频传输、实时通信

DNS

域名解析：由域名查找ip地址。

http请求过程

以下代码会生成一个http请求。客户端向服务器请求

<form method="GET" action="/cgi/sample.cgi">
    <input type="text" name="field">
</form>

根据协议生成消息体
先显示文字，有图片再请求显示图片（不过会预留空间）。由于每条请求消息中只能写一个URI，实验每次只能获取1个文件。如果需要获取多个文件，必须对每个文件单独发送1条请求。

HTTP请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

Content-Type，内容类型，一般是指网页中存在的Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件，这就是经常看到一些Asp网页点击的结果却是下载到的一个文件或一张图片的原因。

实例
来自http://www.runoob.com/http/http-tutorial.html
下面实例是一点典型的使用GET来传递数据的实例：

客户端请求：

GET /hello.txt HTTP/1.1 【请求行： get方法，对hello.txt文件操作，协议版本】
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3【以下是请求头，此例子木有请求正文】
Host: www.example.com 【通过dns找到服务器】
Accept-Language: en, mi 【声明浏览器所用的语言】

请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。

服务端响应:

HTTP/1.1 200 OK 【状态行，200表示返回状态】
Date: Mon, 27 Jul 2009 12:28:53 GMT 【响应头】
Server: Apache 【服务器类                                                                                                    型】
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 【日期】
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51 【长度】
Vary: Accept-Encoding
Content-Type: text/plain
空行
响应正文

相关性质

不保存状态即无状态协议。so引入了cookie

用完整的请求URI来定位资源。

keep-alive:持久连接，减少了tcp连接的重新建立。

相关方法

这些方法是对服务器的一系列操作

1	GET	请求指定的页面信息，并返回实体主体。
2	HEAD	类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
3	POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4	PUT	从客户端向服务器传送的数据取代指定的文档的内容。（类似于上传）
5	DELETE	请求服务器删除指定的页面。
6	CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7	OPTIONS	允许客户端查看服务器的性能。
8	TRACE	回显服务器收到的请求，主要用于测试或诊断。

get&post区别

GET的语义是请求获取指定的资源。

POST的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。请求资源。

直观区别是一个在url中一个在请求体中，一个参数多一个参数比较少。

1. GET请求，浏览器会把http header和data一并发送出去，服务器响应200，返回数据。

2. POST请求，浏览器先发送header，服务器响应100，浏览器再发送data，服务器响应200，返回数据。

   cookie & session

HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。

cookie

客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

有了Cookie这样的技术实现，服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。通常，我们可以从很多网站的登录界面中看到“请记住我”这样的选项，如果你勾选了它之后再登录，那么在下一次访问该网站的时候就不需要进行重复而繁琐的登录动作了，而这个功能就是通过Cookie实现的。

Session

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

session存储及详细论述

后端怎么存储session以及登录验证全过程

session可以持久化为数据库、文件等一系列地方。可以使用Redis存储。

https://blog.csdn.net/qq_15096707/article/details/74012116

在创建了Session的同时，服务器会为该Session生成唯一的Session id，而这个Session id在随后的请求中会被用来重新获得已经创建的Session；在Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中，发到客户端的只有Session id；当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session，从而再次使用之。

（java后台有一系列关于session的方法）

https://www.cnblogs.com/lxp503238/p/6549563.html

会话范围：会话范围是某个用户从首次访问服务器开始，到该用户关闭浏览器结束！

> 会话：一个用户对服务器的多次连贯性请求！所谓连贯性请求，就是该用户多次请求中间没有关闭浏览器！

• 服务器会为每个客户端创建一个session对象，session就好比客户在服务器端的账户，它们被服务器保存到一个Map中，这个Map被称之为session缓存！

  > Servlet中得到session对象：HttpSession session = request.getSession();
  >     > Jsp中得到session对象：session是jsp内置对象之下，不用创建就可以直接使用！
  

• session域相关方法：

  > void setAttribute(String name, Object value);
  >     > Object getAttribute(String name);
  >     > void removeAttribute(String name);
  

session&cookie区别

1. cookie数据存放在客户的浏览器上，session数据放在服务器上；
2. cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session；
3. session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用COOKIE；
4. 单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能超过3K；

Cookie和Session的方案虽然分别属于客户端和服务端，但是服务端的session的实现对客户端的cookie有依赖关系的，上面我讲到服务端执行session机制时候会生成session的id值，这个id值会发送给客户端，客户端每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在客户端会保存下来，保存的容器就是cookie，因此当我们完全禁掉浏览器的cookie的时候，服务端的session也会不能正常使用

状态码

• 200 - 请求成功
• 301 - 资源（网页等）被永久转移到其它URL
• 404 - 请求的资源（网页等）不存在
• 500 - 内部服务器错误

1**正在处理	信息，服务器收到请求，需要请求者继续执行操作
2**处理完毕	成功，操作被成功接收并处理
3**进一步处理	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

301&302：

301：永久性重定向，需要更新书签

302; 暂时性重定向，不一定需要更新书签。

http缓存

强缓存&弱缓存

与传统访问方式不同，CDN网络则是在用户和服务器之间增加缓存层，将用户的访问请求引导到最优的缓存节点而不是服务器源站点，从而加速访问速度。

CDN是将源站内容分发至最接近用户的节点，使用户可就近取得所需内容，提高用户访问的响应速度和成功率。解决因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、点播、直播等场景。最简单的CDN网络由一个DNS服务器和几台缓存服务器组成。

http&https

https

基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护

通过抓包可以看到数据不是明文传输，而且HTTPS有如下特点：

1. 内容加密：采用混合加密技术，中间者无法直接查看明文内容
2. 验证身份：通过证书认证客户端访问的是自己的服务器
3. 保护数据完整性：防止传输的内容被中间人冒充或者篡改

https过程：

来源：https://blog.csdn.net/xiaoming100001/article/details/81109617

1. client向server发送请求https://baidu.com，然后连接到server的443端口。
2. 服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。

【比如来源于CA】

CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书。

区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。

1. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。

1. 客户端解析证书

[解析数字签名是否真实，得到服务器公钥]

这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（秘钥）。然后用证书对该随机值进行加密。

1. 传送加密信息

【利用公钥加密对称密钥】

这部分传送的是用证书加密后的秘钥，目的就是让服务端得到这个秘钥，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6.服务段加密信息
服务端用私钥解密秘密秘钥，得到了客户端传过来的私钥，然后把内容通过该值进行对称加密。

7.传输加密后的信息
这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。

8.客户端解密信息
客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容。