HTTP以及其与HTTPS的区别、javaweb

来源：互联网发布：瓷砖计算软件编辑：程序博客网时间：2024/06/06 07:31

HTTP协议

HTTP属于应用层协议之一，有HTTP/1.0和HTTP/1.1版本。协议的主要特点是：

1.支持客户/服务器模式

2.简单快速：客户向服务器请求服务时，只需请求方法和路径。请求方法常用的有POST/GET。

3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。这应该是针对HTTP/1.0版本的。

5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

二、HTTP请求由三部分组成，分别是：请求行、消息报头、请求正文

GET /books/java.html HTTP/1.1 请求头

Method Request-URI HTTP-Version CRLF

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI（请求资源）和协议的版本号。

Method 表示请求方法：

Request-URI：是一个统一资源标识符

HTTP-Version：请求的协议版本

CRLF ：回车和换行

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET     请求获取Request-URI所标识的资源
POST    在Request-URI所标识的资源后附加新的数据
HEAD    请求获取由Request-URI所标识的资源的响应消息报头
PUT     请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

1 HTTP协议特点

1)客户端->服务端(请求request)有三部份

a)请求行

b)请求头

c)请求的内容，如果没有，就是空白字符

2)服务端->客户端(响应response)有三部份

a)响应行

b)响应头

c)响应的内容，如果没有，就是空白字符

*2 HTTP请求头和响应头含义

1)请求(客户端->服务端[request])

GET(请求的方式) /books/java.html(请求的目标资源) HTTP/1.1(请求采用的协议和版本号)

Accept: */*(客户端能接收的资源类型)

Accept-Language: en-us(客户端接收的语言类型)

Connection: Keep-Alive(维护客户端和服务端的连接关系)

Host: localhost:8080(连接的目标主机和端口号)

Referer: http://localhost/links.asp(从来于哪里)

User-Agent: Mozilla/4.0(客户端版本号的名字)

Accept-Encoding: gzip, deflate(客户端能接收的压缩数据的类型)

If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT(缓存时间)

Cookie(客户端暂存服务端的信息)

Date: Tue, 11 Jul 2000 18:23:51 GMT(客户端请求服务端的时间)

2)响应(服务端->客户端[response])

HTTP/1.1(响应采用的协议和版本号) 200(状态码) OK(描述信息)--------响应行

404客户端请求的资源服务端不存在

302（客户端请求服务端，但服务端没有对应的资源，服务端要客户端再次请求找其它的服务端，即客户端二次请求，重定向redirect）

307（客户端请求服务端，但服务端没有对应的资源，服务端自行再次请求找其它的服务端，即客户端一次请求，转发dispatch）

304（客户端请求服务端，此时客户端缓存中有，无需再从服务端下载新的内容,服务端叫客户端自行找缓存，优化）

500(客户端请求的资源，服务端存在，但在执行时出错）

Location: http://www.baidu.com(服务端需要客户端访问的页面路径)

Server:apache tomcat(服务端的Web服务端名)

Content-Encoding: gzip(服务端能够发送压缩编码类型)

Content-Length: 80(服务端发送的压缩数据的长度)

Content-Language: zh-cn(服务端发送的语言类型)

Content-Type: text/html; charset=GB2312(服务端发送的类型及采用的编码方式)

Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT(服务端对该资源最后修改的时间)

Refresh: 1;url=http://www.it315.org(服务端要求客户端1秒钟后，刷新，然后访问指定的页面路径)

Content-Disposition: attachment; filename=aaa.zip(服务端要求客户端以下载文件的方式打开该文件)

Transfer-Encoding: chunked(分块传递数据到客户端）

Set-Cookie:SS=Q0=5Lb_nQ; path=/search(服务端发送到客户端的暂存数据)

Expires: -1//3种(服务端禁止客户端缓存页面数据)

Cache-Control: no-cache(服务端禁止客户端缓存页面数据)

Pragma: no-cache(服务端禁止客户端缓存页面数据)

Connection: close(1.0)/(1.1)Keep-Alive(维护客户端和服务端的连接关系)

Date: Tue, 11 Jul 2000 18:23:51 GMT(服务端响应客户端的时间)

3)总结

想让浏览器有何种行为，服务端只能通过响应头的方式来设置

想让服务器知道何种行为，浏览器只能通过请求头的方式来设置

2)常用的提交方式

a)GET

特点：请求参数无论多少，都会根着URL后传递到服务端，以明文方式传递

GET方式传递有大小限制

GET方式传递信息不安全

b)POST

特点：

请求参数无论多少，都不会根着URL后传递到服务端，而是以参数形式在请求体中传递到服务端

POST方式传递无大小限制

POST方式传递信息相对安全

GET方式和POST方式的区别：

一、区别

1.效率

GET的意思是『得』，从服务器获取数据（也可以上传数据，参数就是），效率较高

POST的意思是『给』，但可以向服务器发送数据和下载数据，效率不如GET

2.缓存

GET 请求能够被缓存，默认的请求方式也是有缓存的

POST请求默认不会缓存

缓存是针对URL来进行缓存的，GET请求由于其参数是直接加在URL上-的，一种参数组合就有一种URL的缓存，可以根据参数来进行一一对应，重复请求是幂等的（不论请求多少次，结果都一样）;

而POST请求的URL没有参数,每次请求的URL都相同，数据体（HTTPBody）可能不同，无法一一对应，所以缓存没有意义

3.安全性

GET的所有参数全部包装在URL中，明文显示，且服务器的访问日志会记录，非常不安全

POST的URL中只有资源路径，不包含参数，参数封装在二进制的数据体中，服务器也不会记录参数，相对安全。所有涉及用户隐私的数据都要用POST传输

POST的安全是相对的，对于普通用户来说他们看不到明文，数据封装对他们来说就是屏障。但是对于专业人士，它们会抓包会分析，没有加密的数据包对他们来说也是小case。所以POST仅仅是相对安全，唯有对数据进行加密才会更安全。当然加密也有被破解的可能性，理论上所有的加密方式都可以破解，只是时间长短的问题。而加密算法要做的就是使得破解需要的时间尽量长，越长越安全。由于我们也需要解密，加密算法太过复杂也并非好事，这就要结合使用情况进行折中或者足够实际使用即可。绕的有点远，具体的话，我将在后续的文章之中介提及，并介绍一些常用的加密算法。

4.数据量

HTTP协议中均没有对GET和POST请求的数据大小进行限制，但是实际应用中它们通常受限于软硬件平台的设计和性能。

GET：不同的浏览器和服务器不同，一般限制在2~8K之间，更加常见的是1k以内

POST方法提交的数据比较大，大小靠服务器的设定值限制，PHP默认是2M（具体的话大家以后看后端给的开发文档就行了）。

HTTPS；

HTTP的缺点：

1、通信使用明文，不安全，容易遭到窃听

2、不验证通信方的身份，因此有可能遭遇伪装

3、无法验证报文的完整性

如何实现安全呢？

一种方式就是将通信加密。HTTP协议中没有加密机制，但可以通过和SSL（secure socket layer）安全套接层或TLS（Transport LayerSecurity，安全层传输协议）的组合使用，加密的HTTP的通信内容。与SSL组合使用的HTTP被称为HTTPS，超文本传输安全协议。这两种组合方式都是对通信线路进行加密。

还有一种将参与通信的内容本身加密的方式。由于HTTP协议中没有加密机制，那么就对HTTP协议传输的内容本身加密。即把HTTP报文里所含的内容进行加密处理。

在这种情况下，客户端需要对HTTP报文进行加密处理后再发送请求。为了，做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在web服务中。有一点必须注意，由于该方式和SSL或者TSL将整个通信线路加密方式不同，所以内容仍然可能被篡改。

不验证通信方的身份就可能遭遇伪装。

不验证通信方的身份就可能遭遇伪装

HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端”等类似问题。

任何人都可发起请求

在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）。HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患。
1、无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
2、无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
3、无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。
4、无法判定请求是来自何方、出自谁手。

5、即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS 攻击（ Denial of Service，拒绝服务攻击）。

查明对手的证书

虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。
另外，客户端持有证书即可完成个人身份的确认，也可用于对 Web 网站的认证环节。

无法证明报文完整性，可能已遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。

接收到的内容可能有误

由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
换句话说，没有任何办法确认，发出的请求响应和接收到的请求响应是前后相同的。

比如，从某个 Web 网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的已改变，作为接收方的客户端也是觉察不到的。像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。

如何防止篡改

虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。

提供文件下载服务的 Web 网站也会提供相应的以 PGP（Pretty GoodPrivacy，完美隐私）创建的数字签名及 MD5 算法生成的散列值。PGP 是用来证明创建文件的数字签名，MD5 是由单向函数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。
可惜的是，用这些方法也依然无法百分百保证确认结果正确。因为 PGP 和MD5 本身被改写的话，用户是没有办法意识到的。

为了有效防止这些弊端，有必要使用 HTTPS。SSL 提供认证和加密处理及摘要功能。仅靠 HTTP 确保完整性是非常困难的，因此通过和其他协议组合使用来实现这个目标。下节我们介绍 HTTPS 的相关内容。

确保 Web 安全的 HTTPS

在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。

HTTP+ 加密 + 认证 + 完整性保护 =HTTPS

HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS
如果在 HTTP 协议通信过程中使用未经加密的明文，比如在 Web 页面中输入信用卡号，如果这条通信线路遭到窃听，那么信用卡号就暴露了。
另外，对于 HTTP 来说，服务器也好，客户端也好，都是没有办法确认通信方的。
因为很有可能并不是和原本预想的通信方在实际通信。并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能性。
为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS （HTTP Secure）。

经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信。使用 HTTPS 通信时，不再用 http://，而是改用 https://。另外，当浏览器访问 HTTPS 通信有效的 Web网站时，浏览器的地址栏内会出现一个带锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。

HTTPS 是身披 SSL 外壳的 HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）协议代替而已。
通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的HTTP。

在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全术。

相互交换密钥的公开密钥加密技术

在对 SSL 进行讲解之前，我们先来了解一下加密方法。SSL 采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。

近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种方式得以保持加密方法的安全性。
加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。

共享密钥加密的困境

加密和解密同用一个密钥的方式称为共享密钥加密（Common key cryptosystem），也被叫做对称密钥加密。

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

使用两把密钥的公开密钥加密

公开密钥加密方式很好地解决了共享密钥加密的困难。
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。公开密钥和私有密钥是配对的一套密钥。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

HTTPS 采用混合加密机制

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。

但是公开密钥加密与共享密钥加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

证明公开密钥正确性的证书

遗憾的是，公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。
为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。
数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。威瑞信（VeriSign）就是其中一家非常有名的数字证书认证机构。我们来介绍一下数字证书认证机构的业务流程。

首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。
此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

web基本概念

1)JavaWeb是用Java技术开发基于Web的应用

2)在Internet上运行的资源有二大类：

a)静态资源

无论何时何地以何种身份访问该资源，显示的结果一样

HTML或XHTML或XML，CSS，JavaScript,...

b)动态资源

无论何时何地以何种身份访问该资源，有可以结果不一样

Servlet，Jsp，...

安装tomcat web服务器

1)将某个文件提外界用户访问，必须有一个类似的网络应用程序来接收和响应用户的请求

2）web服务器有多种类型

java开源：tomcat6/7..............................................................................................................

商用：weblogic，websphere

3)安装tomcat

a)配置JDK正确版本[至少是JDK5]和路径

b)执行tomcat/bin/startup.bat启动Web服务器

c)CATALINA_HOME指明需要启动哪台tomcat服务器

错误案例：

a)tomcat端口被占用，可以通过server.xml文件修改默认端口号

b)查看当前进程使用情况，工具Fport.exe

c)窗口一闪而过，JAVA_HOME目录设置出错

tomcat目录的含义：

*bin/启动和停止tomcat的脚本文件

*conf/配置tomcat的文本，以xml文件为主

*lib/tomcat用到的第三方jar包

logs/tomcat服务器操作相关的日志文件

temp/tomcat运行时用到的一些临时文件

**webapps/tomcat能被外界访问的符合标准目录结构的web应用

work/tomcat运行的工作目录

5)Web标准目录结构：

tomcat/webapps目录

mail目录(Web应用或Web工程，该Web应用下有N多Web静动态资源)

*.html(静态资源)

6)Web常用的编号

404:客户端请求的资源，服务端找不到

*4 配置虚拟主机和目录

1)虚拟目录：在tomcat/conf/server.xml文件中设置如下代码：

path="以/开头，表示虚拟目录"

docBase="web应用的真实目录"

附加：

reloadable="false"服务端会自动监视/WEB-INF/classes或lib目录下的变化情况，一旦变化，服务湍

在设置成true的情况下，自动加载最新的内容，如果设置成false，服务端无法加载最

新的资源，需要手工重新启动服务器，开发阶段设置为true，上线阶段设置为false。

unpackWAR="true"服务器会自动将web压缩文件解压成标准的web目录结构

2)设置默认web应用

3)设置默认web资源

mail-WEB-INF-web.xml文件中设置如下代码：

<welcome-file-list>

<welcome-file>mail.html</welcome-file>

</welcome-file-list>

4)设置虚拟主机：在tomcat/conf/server.xml文件中设置如下代码：

</Host>

name表示虚拟主机名，与HOSTS文件中定义的一致

appBase虚拟主机对应的Web应用根目录

\表示真实目录

/表示外界通过浏览器访问的目录

以windowXP为例：C:\WINDOWS\system32\drivers\etc\HOSTS文件

5)位于webapps/目录下的标准web应用，服务器会自动映射成一个虚拟目录

6)某些旧版的tomcat服务器，可能无法自动映射webapps/目录下的标准web应用，需要加上WEB-INF/web.xml文件才行

5 理解C/S和B/S结构的特点

1)Domain Name Service

2)DNS是电信内部的一个域名和IP地址的映射关系

3)在查询DNS之前，先查看本地操作系统对应的HOSTS文件，是否能找到对应的IP，如果能找到，不会查DNS了，只有在

查找不到的情况下，再连网找DNS服务器

4)CS结构：程序和数据分离在不同的端

*BS结构：程序和数据绑定在服务端

6 观察http协议

1)超文本的传输协议，是基于TCP/UDP协议（底层）

2)有二个版本

a)HTTP/1.0（一次用户请求，服务端响应后，立即断开）

b)HTTP/1.1（一次用户请求，服务端响应后，会保持一定的时间，在该一定时间后，用户可以再次请求）

3）为了让客户端响应速度快，在满足业务需求的情况下，尽量减少HTTP请求数的发送

www.3158.cn

7 验证http响应头

(1)cn.itcast.web.http.Demo1：302+location

(2)cn.itcast.web.http.Demo2：content-encoding:gzip(使用压缩格式的内容)

content-length:30(压缩内容长度)

GZIPOutputStream->ByteArrayOutputStream

(3)cn.itcast.web.http.Demo3：content-type:(打开文件的类型)

(4)cn.itcast.web.http.Demo4：content-disposition:(下载文件)

(5)cn.itcast.web.http.Demo5：refresh：控制浏览器刷新

(6)cn.itcast.web.http.Demo6：expires:

阅读全文

0 0