http

HTTP

一、基础概念

1. http概念

1.1 http是什么:

1.2 http作用:

1.3 TCP/IP 三次握手的过程:

1.4 HTTP 返回状态码

1.5 URI 、 URL 、 URN。

1.6 HTTP请求头

2. HTTP请求方法(java)

2.1 根据HTTP标准,HTTP请求可以使用多种请求方法。

2.2 GET/POST调用demo:

http://note.youdao.com/noteshare?id=34174fea1a2f7d34603d4e71fac82a22

2.3 可缓存

2.4 XMLHttpRequest

3. cookie与session

二、具体应用

1.http的长连接和短连接

2. 长轮询和短轮询

三、HTTPS

 

 

参考:https://github.com/CyC2018/CS-Notes/blob/master/docs/notes/HTTP.md

 

一、基础概念

1. http概念

1.1 http是什么:

HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。HTTP是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。

简单来说,HTTP协议就是客户端和服务器交互的一种通迅的格式。

1.2 http作用:

在Internet上的Web服务器上存放的都是超文本信息,客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息,不仅可用于Web访问,也可以用于其他因特网/内联网应用系统之间的通信,从而实现各类应用资源超媒体访问的集成。

 

1.3 TCP/IP 三次握手的过程:

第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。

 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;ACK:确认字符(Acknowledgement)

 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

 HTTP协议就是基于TCP/IP协议模型来传输信息的。

 

1.4 HTTP 返回状态码

 

状态码

类别

含义

备注(常见详细含义)

1**

Informational(信息性状态码)

接收的请求正在处理

100:Continue(继续,客户端应继续其请求)

2**

Success(成功状态码)

请求正常处理完毕

200:OK(请求成功。一般用于GET与POST请求)

201:Created(已创建。成功请求并创建了新的资源)

202:Accepted(已接受。已经接受请求,但未处理完成)

203:Non-Authoritative Information(非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本)

204:No Content(无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档)

205:Reset Content(重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域)

206:Partial Content(部分内容。服务器成功处理了部分GET请求)

3**

Redirection(重定向状态码)

需要进行附加操作以完成请求

300:Multiple Choices多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择

301:Moved Permanently永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

302:Found临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

303:See Other查看其它地址。与301类似。使用GET和POST请求查看

304:Not Modified未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

305:Use Proxy使用代理。所请求的资源必须通过代理访问

306:Unused已经被废弃的HTTP状态码

307:Temporary Redirect临时重定向。与302类似。使用GET请求重定向

4**

Client Error(客户端错误状态码)

服务器无法处理请求

400:Bad Request客户端请求的语法错误,服务器无法理解

401:Unauthorized请求要求用户的身份认证

402:Payment Required保留,将来使用

403:Forbidden服务器理解请求客户端的请求,但是拒绝执行此请求

404:Not Found服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面

405:Method Not Allowed客户端请求中的方法被禁止

406:Not Acceptable服务器无法根据客户端请求的内容特性完成请求

407:Proxy Authentication Required请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权

408:Request Time-out服务器等待客户端发送的请求时间过长,超时

409:Conflict服务器完成客户端的PUT请求是可能返回此代码,服务器处理请求时发生了冲突

410:Gone客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置

411:Length Required服务器无法处理客户端发送的不带Content-Length的请求信息

412:Precondition Failed客户端请求信息的先决条件错误

413:Request Entity Too Large由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息

414:Request-URI Too Large请求的URI过长(URI通常为网址),服务器无法处理

415:Unsupported Media Type服务器无法处理请求附带的媒体格式416Requested range not satisfiable客户端请求的范围无效417Expectation Failed服务器无法满足Expect的请求头信息

5**

Server Error(服务器错误状态码)

服务器处理请求出错

500:Internal Server Error服务器内部错误,无法完成请求

501:Not Implemented服务器不支持请求的功能,无法完成请求

502:Bad Gateway作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应

503:Service Unavailable由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中

504:Gateway Time-out充当网关或代理的服务器,未及时从远端服务器获取请求

505:HTTP Version not supported服务器不支持请求的HTTP协议的版本,无法完成处理

 

 

 

1.5 URI 、 URL 、 URN。

URI 包含 URL 和 URN。

  • URI(Uniform Resource Identifier,统一资源标识符)
  • URL(Uniform Resource Locator,统一资源定位符)
  • URN(Uniform Resource Name,统一资源名称)

1. 5.1 URI 统一资源标志符(Universal Resource Identifier, URI)

表示的是web上每一种可用的资源,如 HTML文档、图像、视频片段、程序等都由一个URI进行定位的。

URI通常由三部分组成:

①访问资源的命名机制;

②存放资源的主机名;

③资源自身的名称,由路径表示。

URI举例

如:https://blog.csdn.net/shuted333/article/details/87865

我们可以这样解释它:

①这是一个可以通过https协议访问的资源,

②位于主机 blog.csdn.net上,

③通过路径“/shuted333/article/details/87865”访问。

 

1. 5.2 URL 即统一资源定位符(Uniform Resouce Locator)

用于定位万维网上的文档或数据。URL是URI的一个子集。

通俗地说,URL是Internet上描述信息资源的字符串,主要用在各种WWW客户程序和服务器程序上。

采用URL可以用一种统一的格式来描述各种信息资源,包括文件、服务器的地址和目录等。

URL的一般格式为(带方括号[]的为可选项):

protocol :// hostname[:port] / path / [;parameters][?query]#fragment

URL的格式由三部分组成: 

①第一部分是协议(或称为服务方式)。

②第二部分是存有该资源的主机IP地址(有时也包括端口号)。

③第三部分是主机资源的具体地址,如目录和文件名等。

第一部分和第二部分用“://”符号隔开,

第二部分和第三部分用“/”符号隔开。

第一部分和第二部分是不可缺少的,第三部分有时可以省略。

 

服务端收到了URL后,首先拆解成自己能看懂的东西。 https://www.zhihu.com会被拆解成三部分: https、 www.zhihu.com、/

https表示协议类型,通过这个 Chorme老大哥知道他接下来该如何与远方的网站服务器通信;

www.zhihu.com表示主机名,就是Chorme老大哥要通信的对象了;

第三部分则是它要向服务器要的内容(注:这里表明是空,实际上隐含的表示主目录文件的概念)。

 

1.5.3 URN(Uniform Resource Name,统一资源名称)

 

1.5.4 URI、URL、URN区别:

eg: 

去寻找一个具体的人(URI);

如果用地址:XX省XX市XX区…XX单元XX室的主人 就是URL;

如果用身份证号+名字去找就是URN(身份证号+名字 无法确认资源的地址) 。

 

1.6 HTTP请求头

每个头域由一个域名,冒号(:)和域值三部分组成。

1.6.1通用头部是客户端和服务器都可以使用的头部,可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能,如Date头部。

1.6.2请求头部是请求报文特有的,它们为服务器提供了一些额外信息,比如客户端希望接收什么类型的数据,如Accept头部。

1.6.3响应头部便于客户端提供信息,比如,客服端在与哪种类型的服务器进行交互,如Server头部。

1.6.4实体头部指的是用于应对实体主体部分的头部,比如,可以用实体头部来说明实体主体部分的数据类型,如Content-Type头部。

 

1.6.5 Content-Type

1.6.5.1 Http 请求头 Header里的 Content-Type。

application/x-www-form-urlencoded:数据被编码为名称/值对。这是标准的编码格式。

multipart/form-data: 数据被编码为一条消息,页上的每个控件对应消息中的一个部分。

text/plain: 数据以纯文本形式(text/json/xml/html)进行编码,其中不含任何控件或格式字符。

 

 

 

2. HTTP请求方法(java)

2.1 根据HTTP标准,HTTP请求可以使用多种请求方法。

HTTP1.0定义了三种请求方法: GET, POST 和 HEAD方法。

HTTP1.1新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

序号

方法

描述

安全:

安全的 HTTP 方法不会改变服务器状态,也就是说它只是可读的。

幂等性:

幂等的 HTTP 方法,同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的。

(所有的安全方法都是幂等的。)

1

GET

请求指定的页面信息,并返回实体主体。用于获取资源

2

HEAD

类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头

3

POST

向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。

用于传输实体主体

4

PUT

从客户端向服务器传送的数据取代指定的文档的内容。

5

DELETE

请求服务器删除指定的页面。

6

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

 

7

OPTIONS

允许客户端查看服务器的性能。

 

8

TRACE

回显服务器收到的请求,主要用于测试或诊断。

 

 

2.2 GET/POST调用demo:

http://note.youdao.com/noteshare?id=34174fea1a2f7d34603d4e71fac82a22

 

2.3 可缓存

如果要对响应进行缓存,需要满足以下条件:

3.3.1 请求报文的 HTTP 方法本身是可缓存的,包括 GET 和 HEAD,但是 PUT 和 DELETE 不可缓存,POST 在多数情况下不可缓存的。

3.3.2 响应报文的状态码是可缓存的,包括:200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。

3.3.3 响应报文的 Cache-Control 首部字段没有指定不进行缓存。

 

2.4 XMLHttpRequest

POST 和 GET 的另一个区别,需要先了解 XMLHttpRequest:

XMLHttpRequest 是一个 API,它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式,并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。

在使用 XMLHttpRequest 的 POST 方法时,浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做,例如火狐就不会。

而 GET 方法 Header 和 Data 会一起发送

 

 

 

 

3. cookie与session

3.1 cookie机制

3.1.1 什么是cookie

Cookie意为“甜饼”,是由W3C组织提出,最早由Netscape社区发展的一种机制。目前Cookie已经成为标准,所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

由于HTTP是一种无状态的协议,服务器单从网络连接上无从知道客户身份。怎么办呢?就给客户端们颁发一个通行证吧,每人一个,无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

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

 

 

3.2 Session机制

3.2.1 什么是session:

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

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话,那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案,客户来访的时候只需要查询客户档案表就可以了。

Session机制决定了当前客户只会获取到自己的Session,而不会获取到别人的Session。各客户的Session也彼此独立,互不可见。

提示:Session的使用比Cookie方便,但是过多的Session存储在服务器内存中,会对服务器造成压力。

 

3.2.2 Session的有效期

由于会有越来越多的用户访问服务器,因此Session也会越来越多。为防止内存溢出,服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器,Session就自动失效了。

Session的超时时间为maxInactiveInterval属性,可以通过对应的getMaxInactiveInterval()获取,通过setMaxInactiveInterval(longinterval)修改。

 

3.4  Session的常用方法

方  法  名

描    述

void setAttribute(String attribute, Object value)

设置Session属性。value参数可以为任何JavaObject。通常为Java Bean。value信息不宜过大

String getAttribute(String attribute)

返回Session属性

Enumeration getAttributeNames()

返回Session中存在的属性名

void removeAttribute(String attribute)

移除Session属性

String getId()

返回Session的ID。该ID由服务器自动创建,不会重复

long getCreationTime()

返回Session的创建日期。返回类型为long,常被转化为Date类型,例如:Date createTime = new Date(session.get CreationTime())

long getLastAccessedTime()

返回Session的最后活跃时间。返回类型为long

int getMaxInactiveInterval()

返回Session的超时时间。单位为秒。超过该时间没有访问,服务器认为该Session失效

void setMaxInactiveInterval(int second)

设置Session的超时时间。单位为秒

void putValue(String attribute, Object value)

不推荐的方法。已经被setAttribute(String attribute, Object Value)替代

Object getValue(String attribute)

不被推荐的方法。已经被getAttribute(String attr)替代

boolean isNew()

返回该Session是否是新创建的

void invalidate()

使该Session失效

 

3.2.5 Session对浏览器的要求

虽然Session保存在服务器,对客户端是透明的,它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的,Session不能依据HTTP连接来判断是否为同一客户,因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie,它的值为该Session的id(也就是HttpSession.getId()的返回值)。Session依据该Cookie来识别是否为同一用户。

该Cookie为服务器自动生成的,它的maxAge属性一般为–1,表示仅当前浏览器内有效,并且各浏览器窗口间不共享,关闭浏览器就会失效。

因此同一机器的两个浏览器窗口访问服务器时,会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口(也就是说不是双击桌面浏览器图标等打开的窗口)除外。这类子窗口会共享父窗口的Cookie,因此会共享一个Session。

 

注意:新开的浏览器窗口会生成新的Session,但子窗口除外。子窗口会共用父窗口的Session。例如,在链接上右击,在弹出的快捷菜单中选择“在新窗口中打开”时,子窗口便可以访问父窗口的Session。

如果客户端浏览器将Cookie功能禁用,或者不支持Cookie怎么办?例如,绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案:URL地址重写。

 

3.2.6 URL地址重写

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie,也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写

 

 

 

二、具体应用

1.http的长连接和短连接

什么是长连接:

HTTP1.1规定了默认保持长连接(HTTP persistent connection ,也有翻译为持久连接),数据传输完成了保持TCP连接不断开(不发RST包、不四次握手),等待在同域名下继续用这个通道传输数据;相反的就是短连接。

说HTTP请求和HTTP响应会更准确一些,而HTTP请求和HTTP响应,都是通过TCP连接这个通道来回传输的。

 

 

2. 长轮询和短轮询

而对于客户端来说,不管是长轮询还是短轮询,客户端的动作都是一样的,就是不停的去请求,不同的是服务端,短轮询情况下服务端每次请求不管有没有变化都会立即返回结果,而长轮询情况下,如果有变化才会立即返回结果,而没有变化的话,则不会再立即给客户端返回结果,直到超时为止。

 

 

三、HTTPS

1. HTTP 有以下安全性问题:

1.1使用明文进行通信,内容可能会被窃听;

1.2不验证通信方的身份,通信方的身份有可能遭遇伪装;

1.3无法证明报文的完整性,报文有可能遭篡改。

 

2.HTTPS是如何保证数据的安全?

HTTPS 并不是新协议,而是让 HTTP 先和 SSL(Secure Sockets Layer)通信,再由 SSL 和 TCP 通信,也就是说 HTTPS 使用了隧道进行通信。

通过使用 SSL,HTTPS 具有了加密(防窃听)、认证(防伪装)和完整性保护(防篡改)。

 

2.1 客户端向服务器端发起SSL连接请求;(在此过程中依然存在数据被中间方盗取的可能,下面将会说明如何保证此过程的安全)

2.2 服务器把公钥发送给客户端,并且服务器端保存着唯一的私钥

2.3 客户端用公钥对双方通信的对称秘钥进行加密,并发送给服务器端

2.4 服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密,在此过程中,中间方无法对其解密(即使是客户端也无法解密,因为只有服务器端拥有唯一的私钥),这样保证了对称秘钥在收发过程中的安全,此时,服务器端和客户端拥有了一套完全相同的对称秘钥。

2.5 进行数据传输,服务器和客户端双方用公有的相同的对称秘钥对数据进行加密解密,可以保证在数据收发过程中的安全,即是第三方获得数据包,也无法对其进行加密,解密和篡改。

 

https加密方式:

HTTPS 采用混合的加密机制,使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性,之后使用对称密钥加密进行通信来保证通信过程的效率。(下图中的 Session Key 就是对称密钥)

 

3.简要了解HTTP和HTTPS的区别:

3.1 HTTP 是超文本传输协议,属于明文传输协议;

HTTPS 则是具有安全性的基于ssl加密的传输协议

3.2 HTTP 和 HTTPS 使用的是连接方式不同,而且用的端口也不一样,前者是80,后者是443。

3.3 HTTP 是简单的无状态的连接。

HTTPS 协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比 HTTP 协议安全

3.4 HTTPS 内容经过对称加密,每个连接生成一个唯一的加密密钥(对称秘钥:对称密钥加密又叫专用密钥加密,即发送和接收数据的双方必使用相同的密钥对明文进行加密和解密运算。)

3.5 HTTPS 内容传输经过完整性校验

 

4.HTTPS 的缺点

4.1因为需要进行加密解密等过程,因此速度会更慢;

4.2需要支付证书授权的高额费用。

 

 

5. 加密 、认证、完整性保护

5.1.1 对称密钥加密

对称密钥加密(Symmetric-Key Encryption),加密和解密使用同一密钥。

  • 优点:运算速度快;
  • 缺点:无法安全地将密钥传输给通信方。

5.1.2 非对称密钥加密

非对称密钥加密,又称公开密钥加密(Public-Key Encryption),加密和解密使用不同的密钥。

公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥之后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密。

非对称密钥除了用来加密,还可以用来进行签名。因为私有密钥无法被其他人获取,因此通信发送方使用其私有密钥进行签名,通信接收方使用发送方的公开密钥对签名进行解密,就能判断这个签名是否正确。

  • 优点:可以更安全地将公开密钥传输给通信发送方;
  • 缺点:运算速度慢。

5.2 认证

通过使用  证书  来对通信方进行认证。

数字证书认证机构(CA,Certificate Authority)是客户端与服务器双方都可信赖的第三方机构。

服务器的运营人员向 CA 提出公开密钥的申请,CA 在判明提出申请者的身份之后,会对已申请的公开密钥做数字签名,然后分配这个已签名的公开密钥,并将该公开密钥放入公开密钥证书后绑定在一起。

进行 HTTPS 通信时,服务器会把证书发送给客户端。客户端取得其中的公开密钥之后,先使用数字签名进行验证,如果验证通过,就可以开始通信了。

 

5.3 完整性保护

SSL 提供报文摘要功能来进行完整性保护。

HTTP 也提供了 MD5 报文摘要功能,但不是安全的。例如报文内容被篡改之后,同时重新计算 MD5 的值,通信接收方是无法意识到发生了篡改。

HTTPS 的报文摘要功能之所以安全,是因为它结合了加密和认证这两个操作。试想一下,加密之后的报文,遭到篡改之后,也很难重新计算报文摘要,因为无法轻易获取明文。

 

 

工作原理:

生动的讲解了 一个http请求的全过程: https://chuansongme.com/n/2843169435013

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值