一、http协议的特性http协议是建立在TCP/IP协议之上应用层协议，默认端口为80,8080 http协议的的特点是无状态，无连接 二、http协议的请求利用抓包工具httpwatch可以获取报文 http协议的报文传输的是ASCII码，在TCP/IP协议之上，主要主要分为三部分 请求行、请求头、请求体 请求行第一行，包含三个信息：请求方式，url，http协议版本 GET 请求 GET /books/?sex=man&name=Professional HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Connection: Keep-Alive POST 请求 POST / HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 40 Connection: Keep-Alive sex=man&name=Professional 区别： 1、url可见性： get，参数url可见； post，url参数不可见 2、数据传输上： get，通过拼接url进行传递参数； post，通过body体传输参数 3、缓存性： get请求是可以缓存的 post请求不可以缓存 4、后退页面的反应 get请求页面后退时，不产生影响 post请求页面后退时，会重新提交请求 5、传输数据的大小 get一般传输数据大小不超过2k-4k（根据浏览器不同，限制不一样，但相差不大） post请求传输数据的大小根据php.ini 配置文件设定，也可以无限大。 6、安全性 这个也是最不好分析的，原则上post肯定要比get安全，毕竟传输参数时url不可见，但也挡不住部分人闲的没事在那抓包玩。安全性个人觉得是没多大区别的，防君子不防小人就是这个道理。对传递的参数进行加密，其实都一样。 本质区别： GET产生一个TCP数据包；POST产生两个TCP数据包。 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）； 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。 请求头浏览器向服务器发送一些状态数据，标识数据等等 一个信息一行，包括信息名：信息值 按行分隔 User-Agent: firefox//表示发送请求的浏览器（请求代理端）是firefoxHost: shop.100.com//表示请求的主机域名（基于域名的虚拟主机就是靠这个头判断的）Cookie:name=itcast//浏览器携带的cookie数据。Content-Type: application/x-www-form-urlencoded Content-Length: 40Connection: Keep-Alive 注意，请求头信息，需要使用一个空行结束！ 请求主体请求代理端项服务器端，发送的请求数据！ 典型的就是POST形式发送的表单数据！ get请求，没有请求主体部分！get数据是在请求行中的url上进行传递的！ 三、http协议的响应响应包括：响应行、响应头、响应体 HTTP/1.1 200 0K Date: Tue，19 Nov 2013 03:08:55 GMT Server: Apache/2. 2.22 (Win32) PHP/5.3. 13X- -Powered -By: PHP/5. 3.13Content-Length: 16Content- Type: text/html 响应行响应行包括：协议版本、状态码、状态消息 典型的： 1xx:消息 2xx:成功 3xx:请求被重定向 4xx:浏览器端错误 5xx:服务器端错误 典型： 500 服务器内部错误 404 请求的页面没有找到 403 没有权限 200 请求成功 响应头Content-Type: text/html 内容类型，告知浏览器接下来发送的响应主体数据是什么格式！ Content-Length: 响应主体数据的长度！ Date: 响应的时间。GMT时间！ 响应主体主要的响应数据，在浏览器的主体区域显示的数据都是相应主体！ 注意，每行，包括相应行和响应头，都需要一个 \r\n结尾 四、持久连接HTTP 协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP 协议为无连接的协议）；当使用 Keep-Alive 模式（又称持久连接、连接重用）时，Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。 在 HTTP 1.0 版本中，并没有官方的标准来规定 Keep-Alive 如何工作，因此实际上它是被附加到 HTTP 1.0协议上，如果客户端浏览器支持 Keep-Alive ，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有 Connection: Keep-Alive 的请求时，它也会在响应头中添加一个同样的字段来使用 Keep-Alive 。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过 Keep-Alive 规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。 在 HTTP 1.1 版本中，默认情况下所有连接都被保持，如果加入 "Connection: close" 才关闭。目前大部分浏览器都使用 HTTP 1.1 协议，也就是说默认都会发起 Keep-Alive 的连接请求了，所以是否能完成一个完整的 Keep-Alive 连接就看服务器设置情况。 由于 HTTP 1.0 没有官方的 Keep-Alive 规范，并且也已经基本被淘汰，以下讨论均是针对 HTTP 1.1 标准中的 Keep-Alive 展开的。 注意：
五、分块传输Transfer-EncodingTransfer-Encoding 是一个用来标示 HTTP 报文传输格式的头部值。尽管这个取值理论上可以有很多，但是当前的 HTTP 规范里实际上只定义了一种传输取值——chunked。 如果一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。 每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF （回车及换行），然后是数据本身，最后块CRLF结束。在一些实现中，块大小和CRLF之间填充有白空格（0x20）。 最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。消息最后以CRLF结尾。 HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked25This is the data in the first chunk 1A and this is the second one0 六、HTTP Pipelining（HTTP 管线化）默认情况下 HTTP 协议中每个传输层连接只能承载一个 HTTP 请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求。在使用持久连接的情况下，某个连接上消息的传递类似于 HTTP Pipelining（管线化）是将多个 HTTP 请求整批提交的技术，在传送过程中不需等待服务端的回应。使用 HTTP Pipelining 技术之后，某个连接上的消息变成了类似这样 注意下面几点：
七、http协议的安全性跨站请求伪造（CSRF篡改本地信息） 跨站脚本攻击（XSS，就是在html总嵌入js脚本） HTTP头部攻击 OS命令攻击 SQL注入攻击 目录攻击 Dos攻击 Dos攻击主要是有两种 八、会话跟踪
九、cookie的传递HTTP 头中 |
|
|
