GET 和POST 到底有什么区别？
1. 提交的方式不一样，get请求数据会爱url上面，而post是在请求体
2. 传输数据大小的不一样，get对url长度有限制，而post没有限制
3. 安全性不一样，post比get安全性更高
4. GET在浏览器回退时是无害的，而post会再次提交请求。
5. GET产生的url地址可以被Bookmark而post不可以
6. GET请求会被浏览器主动cache，而post不会除非主动设置
7. GET请求只能进行url编码，而POST支持多种编码方式
8. GET请求参数会被完整保留在浏览器浏览记录里，而POST中的参数不会被保留
9. GET请求在URL中传送的长度有限制，而post没有
10. 对于参数的数据类型，GET只接受ASCII字符，而POST没有限制
11. GET比POST更不安全，因为参数直接暴露在URL上，所以不能传递敏感信息
12. GET参数通过URL传递，POST放在Request body中
对于GET方式的请求，浏览器会把httpheader和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？
1. GET与POST都有自己的语义，不能随便混用。
2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
GET后退按钮/刷新无害，POST数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
GET书签可收藏，POST为书签不可收藏。
GET能被缓存，POST不能缓存 。
GET编码类型application/x-www-form-url，POST编码类型encodedapplication/x-www-form-urlencoded或 multipart/form-data。为二进制数据使用多重编码。
GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中。
GET对数据长度有限制，当发送数据时，GET 方法向URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。POST无限制。
GET只允许ASCII 字符。POST没有限制。也允许二进制数据。
与 POST 相比，GET 的安全性较差，因为所发送的数据是URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！POST比 GET 更安全，因为参数不会被保存在浏览器历史或web 服务器日志中。
GET的数据在URL 中对所有人都是可见的。POST的数据不会显示在 URL 中。
GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。GET和POST还有一个重大区别，简单的说：GET产生一个TCP数据包；POST产生两个TCP数据包。
对于GET方式的请求，浏览器会把httpheader和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
.GET请求的数据会附在URL之后，以?分割URL和传输数据，参数之间以&相连，
POST把提交的数据则放置在是HTTP包的包体中。
2.GET的长度受限于url的长度，而url的长度限制是特定的浏览器和服务器设置的，理论上GET的长度可以无限长。
3.POST是没有大小限制的，HTTP协议规范也没有进行大小限制，起限制作用的是服务器的处理程序的处理能力
4.在ASP中，服务端获取GET请求参数用Request.QueryString，获取POST请求参数用Request.Form。
5.POST的安全性要比GET的安全性高
application json 与form表单的区别?
瀏覽器默認的提交方式就是表單。首先，Content-Type被指定为 application/x-www-form-urlencoded，jQuery的Ajax请求默认方式，其次，数据以键值对形式？key1=value1&key2=value2的方式发送到服务器
1、post和get的选择？
私密性的信息请求使用post。
查询信息和可以想要通过url分享的信息使用get。
get和post的区别主要有以下几方面：
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只接受ASCII字符，而POST没有限制。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生一个TCP数据包；POST产生两个TCP数据包。
对于GET方式的请求，浏览器会把httpheader和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
深入:
GET和POST本质上没有区别
GET和POST是什么？HTTP协议中的两种发送请求的方法。
浏览器的GET和POST
这里特指浏览器中非Ajax的HTTP请求，即从HTML和浏览器诞生就一直使用的HTTP协议中的GET/POST。浏览器用GET请求来获取一个html页面/图片/css/js等资源；用POST来提交一个
表单，并得到一个结果的网页。浏览器将GET和POST定义为：
GET
“读取“一个资源。比如Get到一个html文件。反复读取不应该对访问的数据有副作用。比如”GET一下，用户就下单了，返回订单已受理“，这是不可接受的。没有副作用被称为“幂等“（Idempotent)。
因为GET因为是读取，就可以对GET请求的数据做缓存。这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），或者做到server端（用Etag，至少可以减少带宽消耗）
POST
在页面里 标签会定义一个表单。点击其中的submit元素会发出一个POST请求让服务器做一件事。这件事往往是有副作用的，不幂等的。
不幂等也就意味着不能随意多次执行。因此也就不能缓存。比如通过POST下一个单，服务器创建了新的订单，然后返回订单成功的界面。这个页面不能被缓存。试想一下，如果POST请求被浏览器缓存了，那么下单请求就可以不向服务器发请求，而直接返回本地缓存的“下单成功界面”，却又没有真的在服务器下单。那是一件多么滑稽的事情。
因为POST可能有副作用，所以浏览器实现为不能把POST请求保存为书签。想想，如果点一下书签就下一个单，是不是很恐怖？。
此外如果尝试重新执行POST请求，浏览器也会弹一个框提示下这个刷新可能会有副作用，询问要不要继续。
在chrome中尝试重新提交表单会弹框。
当然，服务器的开发者完全可以把GET实现为有副作用；把POST实现为没有副作用。只不过这和浏览器的预期不符。把GET实现为有副作用是个很可怕的事情。我依稀记得很久之前百度贴吧有一个因为使用GET请求可以修改管理员的权限而造成的安全漏洞。反过来，把没有副作用的请求用POST实现，浏览器该弹框还是会弹框，对用户体验好处改善不大。
但是后边可以看到，将HTTPPOST作为接口的形式使用时，就没有这种弹框了。于是把一个POST请求实现为幂等就有实际的意义。POST幂等能让很多业务的前后端交互更顺畅，以及避免一些因为前端bug，触控失误等带来的重复提交。将一个有副作用的操作实现为幂等必须得从业务上能定义出怎么就算是“重复”。如提交数据中增加一个dedupKey在一个交易会话中有效，或者利用提交的数据里可以天然当dedupKey的字段。这样万一用户强行重复提交，服务器端可以做一次防护。
GET和POST携带数据的格式也有区别。当浏览器发出一个GET请求时，就意味着要么是用户自己在浏览器的地址栏输入，要不就是点击了html里a标签的href中的url。所以其实并不是GET只能用url，而是浏览器直接发出的GET只能由一个url触发。所以没办法，GET上要在url之外带一些参数就只能依靠url上附带querystring。但是HTTP协议本身并没有这个限制。
浏览器的POST请求都来自表单提交。每次提交，表单的数据被浏览器用编码到HTTP请求的body里。浏览器发出的POST请求的body主要有有两种格式，一种是application/x-www-form-urlencoded用来传输简单的数据，大概就是"key1=value1&key2=value2"这样的格式。另外一种是传文件，会采用multipart/form-data格式。采用后者是因为application/x-www-form-urlencoded的编码方式对于文件这种二进制的数据非常低效。
浏览器在POST一个表单时，url上也可以带参数，只要<formaction="url" >里的url带querystring就行。只不过表单里面的那些用等标签经过用户操作产生的数据都在会在body里。
因此我们一般会泛泛的说“GET请求没有body，只有url，请求数据放在url的querystring中；POST请求的数据在body中“。但这种情况仅限于浏览器发请求的场景。
接口中的GET和POST
这里是指通过浏览器的Ajaxapi，或者iOS/Android的App的http client，java的commons-httpclient/okhttp或者是curl，postman之类的工具发出来的GET和POST请求。此时GET/POST不光能用在前端和后端的交互中，还能用在后端各个子服务的调用中（即当一种RPC协议使用）。尽管RPC有很多协议，比如thrift，grpc，但是http本身已经有大量的现成的支持工具可以使用，并且对人类很友好，容易debug。HTTP协议在微服务中的使用是相当普遍的。
当用HTTP实现接口发送请求时，就没有浏览器中那么多限制了，只要是符合HTTP格式的就可以发。HTTP请求的格式，大概是这样的一个字符串（为了美观，我在\r\n后都换行一下）：
HTTP/1.1\r\n
: \r\n
: \r\n
...
: \r\n
\r\n
其中的“"可以是GET也可以是POST，或者其他的HTTP Method，如PUT、DELETE、OPTION……。从协议本身看，并没有什么限制说GET一定不能没有body，POST就一定不能把参放到的querystring上。因此其实可以更加自由的去利用格式。比如ElasticSearch的_searchapi就用了带body的GET；也可以自己开发接口让POST一半的参数放在url的querystring里，另外一半放body里；你甚至还可以让所有的参数都放Header里——可以做各种各样的定制，只要请求的客户端和服务器端能够约定好。
当然，太自由也带来了另一种麻烦，开发人员不得不每次讨论确定参数是放url的path里，querystring里，body里，header里这种问题，太低效了。于是就有了一些列接口规范/风格。其中名气最大的当属REST。REST充分运用GET、POST、PUT和DELETE，约定了这4个接口分别获取、创建、替换和删除“资源”，REST最佳实践还推荐在请求体使用json格式。这样仅仅通过看HTTP的method就可以明白接口是什么意思，并且解析格式也得到了统一。
json相对于x-www-form-urlencoded的优势在于1）可以有嵌套结构；以及2）可以支持更丰富的数据类型。通过一些框架，json可以直接被服务器代码映射为业务实体。用起来十分方便。但是如果是写一个接口支持上传文件，那么还是multipart/form-data格式更合适。
REST中GET和POST不是随便用的。在REST中, 【GET】 + 【资源定位符】被专用于获取资源或者资源列表，比如：
GET foo.com/books 获取书籍列表
GET foo.com/books/:book… 根据bookId获取一本具体的书
与浏览器的场景类似，RESTGET也不应该有副作用，于是可以被反复无脑调用。浏览器（包括浏览器的Ajax请求）对于这种GET也可以实现缓存（如果服务器端提示了明确需要Caching）；但是如果用非浏览器，有没有缓存完全看客户端的实现了。当然，也可以从整个App角度，也可以完全绕开浏览器的缓存机制，实现一套业务定制的缓存框架。
okhttp中控制Cache的类
REST 【POST】+ 【资源定位符】则用于“创建一个资源”，比如：
POST foo.com/books
{
"title": "大宽宽的碎碎念",
"author": "大宽宽",
...
}
这里你就能留意到浏览器中用来实现表单提交的POST，和REST里实现创建资源的POST语义上的不同。
顺便讲下RESTPOST和RESTPUT的区别。有些api是使用PUT作为创建资源的Method。PUT与POST的区别在于，PUT的实际语义是“replace”replace。REST规范里提到PUT的请求体应该是完整的资源，包括id在内。比如上面的创建一本书的api也可以定义为：
PUT foo.com/books
{
"id":"BOOK:affe001bbe0556a",
"title": "大宽宽的碎碎念",
"author": "大宽宽",
...
}
服务器应该先根据请求提供的id进行查找，如果存在一个对应id的元素，就用请求中的数据整体替换已经存在的资源；如果没有，就用“把这个id对应的资源从【空】替换为【请求数据】“。直观看起来就是“创建”了。
与PUT相比，POST更像是一个“factory”，通过一组必要的数据创建出完整的资源。
至于到底用PUT还是POST创建资源，完全要看是不是提前可以知道资源所有的数据（尤其是id），以及是不是完整替换。比如对于AWS S3这样的对象存储服务，当想上传一个新资源时，其id就是“ObjectName”可以提前知道；同时这个api也总是完整的replace整个资源。这时的api用PUT的语义更合适；而对于那些id是服务器端自动生成的场景，POST更合适一些。
有点跑题，就此打住。
AWS S3 创建一个Object的API描述
回到接口这个主题，上面仅仅粗略介绍了REST的情况。但是现实中总是有REST的变体，也可能用非REST的协议（比如JSON-RPC、SOAP等），每种情况中的GET和POST又会有所不同。
关于安全性
我们常听到GET不如POST安全，因为POST用body传输数据，而GET用url传输，更加容易看到。但是从攻击的角度，无论是GET还是POST都不够安全，因为HTTP本身是明文协议。每个HTTP请求和返回的每个byte都会在网络上明文传播，不管是url，header还是body。这完全不是一个“是否容易在浏览器地址栏上看到“的问题。
为了避免传输中数据被窃取，必须做从客户端到服务器的端端加密。业界的通行做法就是https——即用SSL协议协商出的密钥加密明文的http数据。这个加密的协议和HTTP协议本身相互独立。如果是利用HTTP开发公网的站点/App，要保证安全，https是最最基本的要求。
当然，端端加密并不一定非得用https。比如国内金融领域都会用私有网络，也有GB的加密协议SM系列。但除了军队，金融等特殊机构之外，似乎并没有必要自己发明一套类似于ssl的协议。
回到HTTP本身，的确GET请求的参数更倾向于放在url上，因此有更多机会被泄漏。比如携带私密信息的url会展示在地址栏上，还可以分享给第三方，就非常不安全了。此外，从客户端到服务器端，有大量的中间节点，包括网关，代理等。他们的access log通常会输出完整的url，比如nginx的默认access log就是如此。如果url上携带敏感数据，就会被记录下来。但请注意，就算私密数据在body里，也是可以被记录下来的，因此如果请求要经过不信任的公网，避免泄密的唯一手段就是https。这里说的“避免access log泄漏“仅仅是指避免可信区域中的http代理的默认行为带来的安全隐患。比如你是不太希望让自己公司的运维同学从公司主网关的log里看到用户的密码吧。
另外，上面讲过，如果是用作接口，GET实际上也可以带body，POST也可以在url上携带数据。所以实际上到底怎么传输私密数据，要看具体场景具体分析。当然，绝大多数场景，用POST + body里写私密数据是合理的选择。一个典型的例子就是“登录”：
POST foo.com/user/login
{
"username":"dakuankuan",
"passowrd":"12345678"
}
安全是一个巨大的主题，有由很多细节组成的一个完备体系，比如返回私密数据的mask，XSS，CSRF，跨域安全，前端加密，钓鱼，salt，…… POST和GET在安全这件事上仅仅是个小角色。因此单独讨论POST和GET本身哪个更安全意义并不是太大。只要记得一般情况下，私密数据传输用POST + body就好。
关于编码
常见的说法有，比如GET的参数只能支持ASCII，而POST能支持任意binary，包括中文。但其实从上面可以看到，GET和POST实际上都能用url和body。因此所谓编码确切地说应该是http中url用什么编码，body用什么编码。
先说下url。url只能支持ASCII的说法源自于RFC1738
Thus, onlyalphanumerics, the special characters "$-_.+!*'(),", and
reserved characters usedfor their reserved purposes may be used
unencoded within a URL.
实际上这里规定的仅仅是一个ASCII的子集[a-zA-Z0-9$-_.+!*'(),]。它们是可以“不经编码”在url中使用。比如尽管空格也是ASCII字符，但是不能直接用在url里。
那这个“编码”是什么呢？如果有了特殊符号和中文怎么办呢？一种叫做percentencoding的编码方法就是干这个用的：
这也就是为啥我们偶尔看到url里有一坨%和16位数字组成的序列。
使用Percent Encoding，即使是binary data，也是可以通过编码后放在URL上的。
但要特别注意，这个编码方式只管把字符转换成URL可用字符，但是却不管字符集编码（比如中文到底是用UTF8还是GBK）这块早期一直都相当乱，也没有什么统一规范。比如有时跟网页编码一样，有的是操作系统的编码一样。最要命的是浏览器的地址栏是不受开发者控制的。这样，对于同样一个带中文的url，如果有的浏览器一定要用GBK（比如老的IE8），有的一定要用UTF8（比如chrome）。后端就可能认不出来。对此常用的办法是避免让用户输入这种带中文的url。如果有这种形式的请求，都改成用户界面上输入，然后通过Ajax发出的办法。Ajax发出的编码形式开发者是可以100%控制的。
不过目前基本上utf8已经大一统了。现在的开发者除非是被国家规定要求一定要用GB系列编码的场景，基本上不会再遇到这类问题了。
关于url的编码，阮一峰的一篇文章有比较详细的解释：
关于URL编码 - 阮一峰的网络日志www.ruanyifeng.com
顺便说一句，尽管在浏览器地址栏可以看到中文。但这种url在发送请求过程中，浏览器会把中文用字符编码+Percent Encode翻译为真正的url，再发给服务器。浏览器地址栏里的中文只是想让用户体验好些而已。
再讨论下Body。HTTP Body相对好些，因为有个Content-Type来比较明确的定义。比如：
POST xxxxxx HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded ; charset=UTF-8
这里Content-Type会同时定义请求body的格式（application/x-www-form-urlencoded）和字符编码（UTF-8）。
所以body和url都可以提交中文数据给后端，但是POST的规范好一些，相对不容易出错，容易让开发者安心。对于GET+url的情况，只要不涉及到在老旧浏览器的地址栏输入url，也不会有什么太大的问题。
回到POST，浏览器直接发出的POST请求就是表单提交，而表单提交只有application/x-www-form-urlencoded针对简单的key-value场景；和multipart/form-data，针对只有文件提交，或者同时有文件和key-value的混合提交表单的场景。
如果是Ajax或者其他HTTP Client发出去的POST请求，其body格式就非常自由了，常用的有json，xml，文本，csv……甚至是你自己发明的格式。只要前后端能约定好即可。
浏览器的POST需要发两个请求吗？
上文中的"HTTP 格式“清楚的显示了HTTP请求可以被大致分为“请求头”和“请求体”两个部分。使用HTTP时大家会有一个约定，即所有的“控制类”信息应该放在请求头中，具体的数据放在请求体里“。于是服务器端在解析时，总是会先完全解析全部的请求头部。这样，服务器端总是希望能够了解请求的控制信息后，就能决定这个请求怎么进一步处理，是拒绝，还是根据content-type去调用相应的解析器处理数据，或者直接用zero copy转发。
比如在用Java写服务时，请求处理代码总是能从HttpSerlvetRequest里getParameter/Header/url。这些信息都是请求头里的，框架直接就解析了。而对于请求体，只提供了一个inputstream，如果开发人员觉得应该进一步处理，就自己去读取和解析请求体。这就能体现出服务器端对请求头和请求体的不同处理方式。
举个实际的例子，比如写一个上传文件的服务，请求url中包含了文件名称，请求体中是个尺寸为几百兆的压缩二进制流。服务器端接收到请求后，就可以先拿到请求头部，查看用户是不是有权限上传，文件名是不是符合规范等。如果不符合，就不再处理请求体的数据了，直接丢弃。而不用等到整个请求都处理完了再拒绝。
为了进一步优化，客户端可以利用HTTP的Continued协议来这样做：客户端总是先发送所有请求头给服务器，让服务器校验。如果通过了，服务器回复“100 - Continue”，客户端再把剩下的数据发给服务器。如果请求被拒了，服务器就回复个400之类的错误，这个交互就终止了。这样，就可以避免浪费带宽传请求体。但是代价就是会多一次Round Trip。如果刚好请求体的数据也不多，那么一次性全部发给服务器可能反而更好。
基于此，客户端就能做一些优化，比如内部设定一次POST的数据超过1KB就先只发“请求头”，否则就一次性全发。客户端甚至还可以做一些Adaptive的策略，统计发送成功率，如果成功率很高，就总是全部发等等。不同浏览器，不同的客户端（curl，postman）可以有各自的不同的方案。不管怎样做，优化目的总是在提高数据吞吐和降低带宽浪费上做一个折衷。
因此到底是发一次还是发N次，客户端可以很灵活的决定。因为不管怎么发都是符合HTTP协议的，因此我们应该视为这种优化是一种实现细节，而不用扯到GET和POST本身的区别上。更不要当个什么世纪大发现。
到底什么算请求体
看完了上面的内容后，读者也许会对“什么是请求体”感到困惑不已，比如x-www-form-endocded编码的body算不算“请求体”呢？
从HTTP协议的角度，“请求头”就是Method + URL（含querystring）+ Headers；再后边的都是请求体。
但是从业务角度，如果你把一次请求立即为一个调用的话。比如上面的
POST foo.com/books
{
"title": "大宽宽的碎碎念",
"author": "大宽宽",
...
}
用Java写大概等价于
createBook("大宽宽的碎碎念", "大宽宽");
那么这一行函数名和两个参数都可以看作是一个请求，不区分头和体。即便用HTTP协议实现，title和author编码到了HTTP请求体中。Java的HttpServletRequest支持用getParameter方法获取x-www-url-form-encoded中的数据，表达的意思就是“请求“的”参数“。
对于HTTP，需要区分【头】和【体】，HttpRequest和HttpResponse都这么区分。Http这么干主要用作：
• 对于HTTP代理
○ 支持转发规则，比如nginx先要解析请求头，拿到URL和Header才能决定怎么做（转发proxy_pass，重定向redirect，rewrite后重新判断……）
○ 需要用请求头的信息记录log。尽管请求体里的数据也可以记录，但一般只记录请求头的部分数据。
○ 如果代理规则不涉及到请求体，那么请求体就可以不用从内核态的page cache复制一份到用户态了，可以直接zero copy转发。这对于上传文件的场景极为有效。
○ ……
• 对于HTTP服务器
○ 可以通过请求头进行ACL控制，比如看看Athorization头里的数据是否能让认证通过
○ 可以做一些拦截，比如看到Content-Length里的数太大，或者Content-Type自己不支持，或者Accept要求的格式自己无法处理，就直接返回失败了。
○ 如果body的数据很大，利用Stream API，可以方便支持一块一块的处理数据，而不是一次性全部读取出来再操作，以至于占用大量内存。
○ ……
但从高一级的业务角度，我们在意的其实是【请求】和【返回】。当我们在说“请求头”这三个字时，也许实际的意思是【请求】。而用HTTP实现【请求】时，可能仅仅用到【HTTP的请求头】（比如大部分GET请求），也可能是【HTTP请求头】+【HTTP请求体】（比如用POST实现一次下单）。
总之，这里有两层，不要混哦。
关于URL的长度
因为上面提到了不论是GET和POST都可以使用URL传递数据，所以我们常说的“GET数据有长度限制“其实是指”URL的长度限制“。
HTTP协议本身对URL长度并没有做任何规定。实际的限制是由客户端/浏览器以及服务器端决定的。
先说浏览器。不同浏览器不太一样。比如我们常说的2048个字符的限制，其实是IE8的限制。并且原始文档的说的其实是“URL的最大长度是2083个字符，path的部分最长是2048个字符“。见support.microsoft.com/en-us/help/… URL限制我没有查到明确的文档，但有些资料称IE11的地址栏只能输入法2047个字符，但是允许用户点击html里的超长URL。我没实验，哪位有兴趣可以试试。
Chrome的URL限制是2MB，见chromium.googlesource.com/chromium/sr…
Safari，Firefox等浏览器也有自己的限制，但都比IE大的多，这里就不挨个列出了。
然而新的IE已经开始使用Chrome的内核了，也就意味着“浏览器端URL的长度限制为2048字符”这种说法会慢慢成为历史。
其他的客户端，比如Java的，js的http client大多数也并没有限制URL最大有多长。
除了浏览器，服务器这边也有限制，比如apache的LimieRequestLine指令。
apache实际上限制的是HTTP请求第一行“Request Line“的长度，即 那一行。
再比如nginx用large_client_header_buffers指令来分配请求头中的很长数据的buffer。这个buffer可以用来处理url，header value等。
Tomcat的限制是web.xml里maxHttpHeaderSize来设置的，控制的是整个“请求头”的总长度。
为啥要限制呢？如果写过解析一段字符串的代码就能明白，解析的时候要分配内存。对于一个字节流的解析，必须分配buffer来保存所有要存储的数据。而URL这种东西必须当作一个整体看待，无法一块一块处理，于是就处理一个请求时必须分配一整块足够大的内存。如果URL太长，而并发又很高，就容易挤爆服务器的内存；同时，超长URL的好处并不多，我也只有处理老系统的URL时因为不敢碰原来的逻辑，又得追加更多数据，才会使用超长URL。
对于开发者来说，使用超长的URL完全是给自己埋坑，需要同时要考虑前后端，以及中间代理每一个环节的配置。此外，超长URL会影响搜索引擎的爬虫，有些爬虫甚至无法处理超过2000个字节的URL。这也就意味着这些URL无法被搜到，坑爹啊。
其实并没有太大必要弄清楚精确的URL最大长度限制。我个人的经验是，只要某个要开发的资源/api的URL长度有可能达到2000个bytes以上，就必须使用body来传输数据，除非有特殊情况。至于到底是GET+ body还是POST+ body可以看情况决定。
留意，1个汉字字符经过UTF8编码 + percent encoding后会变成9个字节，别算错哦。
总结
上面讲了一大堆，是希望读者不要死记硬背GET和POST的区别，而是能从更广的层面去看待和思考这个问题。
最后，协议都是人定的。只要客户端和服务器能彼此认同，就能工作。在常规的情况下，用符合规范的方式去实现系统可以减少很多工作量——大家都约定好了，就不要折腾了。但是，总会有一些情况用常规规范不合适，不满足需求。这时思路也不能被规范限制死，更不要死抠RFC。这些规范也许不能处理你遇到的特殊问题。比如：
• Elastic Search的_search接口使用GET，却用body来表达查询，因为查询很复杂，用querystring很麻烦，必须用json格式才舒服，在请求体用json编码更加容易，不用折腾percentencoding。
• 用POST写一个接口下单时可能也要考虑幂等，因为前端可能实现“下单按键”有bug，造成用户一次点击发出N个请求。你不能说因为POSTby design应该是不幂等就不管了。
协议是死的，人是活的。遇到实际的问题时灵活的运用手上的工具满足需求就好。
面试中http和https的区别与联系
HTTP特点
1.支持客户/服务器模式。（C/S模式）
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快
http协议的特征：
支持客户/服务器模式，2，简单快速，3，灵活，4，无连接，5，无状态。
Https的优点
1、使用Https协议可认证用户和服务器，确保数据发送到正确的客户机和服务器。
2、Https协议是由SSL+Http协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、修改，确保数据的完整性。
3、Https是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
Https的缺点（对比优点）
1、Https协议握手阶段比较费时，会使页面的加载时间延长近。
2、Https连接缓存不如Http高效，会增加数据开销，甚至已有的安全措施也会因此而受到影响；
3、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
4、Https协议的加密范围也比较有限。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
HTTP与HTTPS有什么区别？
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（SecureSockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
http工作流
1. 浏览器查找域名的 IP 地址。这一步包括 DNS 具体的查找过程，包括：浏览器缓存 -> 系统缓存-> 路由器缓存……
2. 浏览器向 web 服务器发送一个 http 请求：三次握手、传送数据、四次挥手;
3. 服务器的永久重定向响应：返回真正访问的地址;
4. 浏览器跟踪重定向地址：另发一个 http 请求;
5. 服务器处理请求;
6. 服务器返回一个 http 响应;
7. 浏览器显示 html 页面：解析 html 以构建 DOM 树 –> 构建渲染树 –> 布局渲染树 –> 绘制渲染树;
8. 浏览器发送请求，获取嵌入在 html 中的资源（如图片、音频、视频、CSS 、JS 等等）;
9. 浏览器发送异步请求。
http请求
http与https的区别
在URL前加https://前缀表明是用SSL加密的。你的电脑与服务器之间收发的信息传输将更加安全。 Web服务器启用SSL需要获得一个服务器证书并将该证书与要使用SSL的服务器绑定。 http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议
要比http协议安全
HTTPS（SecureHypertext Transfer Protocol）安全超文本传输协议
它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。
它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安全全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。）SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。
HTTPS和HTTP的区别：
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
http的连接很简单,是无状态的
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全
HTTPS解决的问题：
1 . 信任主机的问题. 采用https的server 必须从CA 申请一个用于证明服务器用途类型的证书.改证书只有用于对应的server的时候,客户度才信任次主机.所以目前所有的银行系统网站,关键部分应用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全.这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue还是从公众的地方issue, 客户端都是自己人,所以我们也就肯定信任该server.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https, 就是server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥. 一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的. 第三方即使截获,也没有任何意义.因为他没有密钥. 当然窜改也就没有什么意义了.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码,还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还密钥和确认加密算法的需要.单握手就需要6/7 个往返.
i. 任何应用中,过多的roundtrip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求,都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片.如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.
ii. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示
http和https使用的是完全不同的连接方式，同时使用的端口也不同，http使用的是80端口，https使用的是443端口。http的连接很简单，是无状态的，而HTTPS协议是由SSL和HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS安全超文本传输协议是一个安全通信通道，基于HTTP开发，用于在客户计算机和服务器之间交换信息。http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。简单来说它是HTTP的安全版。
区别统计：HTTP是不安全的，而HTTPS是安全的；HTTP标准端口是80，而HTTPS的标准端口是443；在网络模型中，HTTP工作于应用层，而HTTPS工作在传输层；HTTP无需证书，而HTTPS需要认证证书。
cookie与session的区别
cookie session 备注
性能 高 低 session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用cookie。
安全性 低 高 用户可以分析存放在本地的cookie并进行cookie欺骗
存储内容 字符串 任何信息
存储位置 浏览器 服务器
大小 <4K 无限制 session一般只有时间限制，没有大小限制,但是session是在服务器端的，应该节约服务器端的资源；而cookie很多浏览器都限制一个站点最多保存20个cookie。
1、cookie数据存放在客户的浏览器上，session数据存放在服务器上；
2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗；
考虑到安全应当使用session
3、session会在一定时间内保存在服务器上，当访问量增加时，会比较占用服务器的性能；
考虑到减轻服务器性能方面，应当使用cookie
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie；
5、将登录信息等重要信息存放在cookie，其他信息如果需要保留，可以放在cookie中；
sessionStorage localStorage 和cookie之间的区别
共同点：都是保存在浏览器端，且同源的
区别：
1、cookie数据自始至终在同源的http请求中携带，即cookie在浏览器和服务器间来回传递，而sessionStorage和localStorage不会自动把数据发给服务器，仅在本地保存。cookie数据还有路径的概念，可以限制cookie只属于某个路径下。
2、存储大小限制也不同，cookie数据不能超过4K，同时每次http请求都会携带cookie，所以cookie只适合保存很小的数据，如会话标识，sessionStorage和localStorage虽然也有存储大小的限制，但比cookie大得多，可以达到5M或者更大。
3、数据有效期不同，sessionStorage仅在当前浏览器窗口关闭前有效，自然也就不可能持久保持
localStorage始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；cookie只在设置的cookie过期时间之前一直有效，即使窗口或浏览器关闭
4、作用域不同，sessionStorage不在不同的浏览器窗口中共享，即使是同一个页面；localStorage在所有同源窗口中都是共享的，cookie也是在所有同源窗口中都是共享的
5、WEBStorage支持事件通知机制，可以将数据更新的通知发送给监听者
6、WEBStorage的api接口使用更方便
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用服务器的性能，考虑到服务器性能方面，应当使用cookie。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、我认为将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中
cookie
sessionid是服务器和客户端连接时候随机分配的，如果浏览器使用的是cookie，那么所有数据都保存在浏览器端，比如你登陆以后，服务器设置了cookie用户名，那么当你再次请求服务器的时候，浏览器会将用户名一块发送给服务器，这些变量有一定的特殊标记。服务器会解释为cookie变量，所以只要不关闭浏览器，那么cookie变量一直是有效的，所以能够保证长时间不掉线。
如果你能够截获某个用户的cookie变量，然后伪造一个数据包发送过去，那么服务器还是 认为你是合法的。所以，使用cookie被攻击的可能性比较大。
如果cookie设置了有效值，那么cookie会保存到客户端的硬盘上，下次在访问网站的时候，浏览器先检查有没有cookie，如果有的话，读取cookie，然后发送给服务器。
所以你在机器上面保存了某个论坛cookie，有效期是一年，如果有人入侵你的机器，将你的cookie拷走，放在他机器下面，那么他登陆该网站的时候就是用你的身份登陆的。当然，伪造的时候需要注意，直接copy cookie文件到cookie目录，浏览器是不认的，他有一个index.dat文件，存储了 cookie文件的建立时间，以及是否有修改，所以你必须先要有该网站的 cookie文件，并且要从保证时间上骗过浏览器
两个都可以用来存私密的东西，session过期与否，取决于服务器的设定。cookie过期与否，可以在cookie生成的时候设置进去。
区别对比：
(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
(4)单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。
(5)所以：将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中
• cookie数据存放在客户的浏览器上，session数据放在服务器上
• cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑*到安全应当使用session
• session会在一定时间内保存在服务器上，当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie
•单个cookie保存的数*据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie
•建议将登录信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中
• session保存在服务器，客户端不知道其中的信心；cookie保存在客户端，服务器能够知道其中的信息
• session中保存的是对象，cookie中保存的是字符串
• session不能区分路径，同一个用户在访问一个网站期间，所有的session在任何一个地方都可以访问到，而cookie中如果设置了路径参数，那么同一个网站中不同路径下的cookie互相是访问不到的
（1）cookie数据存放在客户的浏览器上，session数据放在服务器上
（2）cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session
（3）session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面应当使用cookie
（4）单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie
（5）可以将登陆信息等重要信息存放为session；其他信息需要保存，可以放在cookie
Cookie和session
什么是cookie？
分为两种方式
临时性的内存cookie
相关的cookie信息存放在浏览器的缓存中
如果浏览器关闭后，cookie信息被释放
安全性高
易用性差
硬盘cookie
cookie信息是保存在客户端机器的硬盘中
永久保存，可以反复读取，除非用户执行删除
易用性好
安全性差
为什么要有cookie，它的作用是什么？
1.访问网站，每次都需要输入用户名和密码
不太方便
只输入用户名的一部分或全部
密码自动出现在对应的文本框中
用户会觉得很方便
大大提高用户访问网站的频率
安全性有隐患
解决方案
增加验证码输入
手机短信验证码
1.提高用户的访问频率，增强易用性
2.登录某个网站后，会有欢迎xxxx使用该网站
通过读取cookie信息，了解用户名，提高网站的亲和力
3.通过对用户访问习惯的记录，提供一些个性化的服务
旅游网站
查询一些目的地
记录在cookie中
等到下次访问时，网站会自动根据我们查询过的关键字，主动把一些用户关注的信息，放在显要位置或置前
提升用户体验
统计网站用户经常查询的关键字有哪些，对这些关键字进行统计和排序
去西藏，可能开发更多的关于西藏的内容，供用户查询、使用或购买
来提升网站的效益
用户经常性的购买某一类商品，在登录后，系统可以自动推送相关的内容
4.统计访问网站的登录时间
压力性能测试的时间点
进行广告的推送
访问网站的时长
粉丝级客户
普通级客户
cookie测试
1.访问网站，每次都需要输入用户名和密码
分第一次登录还是非第一次登录
1.第一次登录后
检查是否在对应路径生成相应的cookie文件
沟通问题
开发问题
cookie存放在何处？
默认存放地点
用户修改浏览器存放位置
2.不是第一次登录
异常测试点1
本地cookie文件被删除
1.第一次登录
产生了cookie文件
2.把对应的cookie文件删除
3.关闭浏览器重新打开，再次进行登录
4.预期输出：重新生成cookie文件
异常测试点2
对应的cookie文件存放路径所在磁盘空间已满
无法创建cookie文件，系统是否有正常的提示
异常测试点3
1.登录
2.生成cookie文件
3.cookie路径进行修改
4.再重新登录
5.预期输出，生成新的cookie文件
异常测试点4
cookie文件只在登录成功后，进行保存
登录不成功的情况，是不应该生成cookie文件
异常测试点5
1.登录
2.生成cookie
3.重新修改密码
4.退出
5.再次登录后
6.预期输出
cookie文件应该进行自动修改
安全性测试点
加密存储的
加密是正确的
找到开发
cookie文件的解密程序
解密后
用户名和密码的信息要与登录信息一致
2.登录某个网站后，会有欢迎xxxx使用该网站
3.通过对用户访问习惯的记录，提供一些个性化的服务
旅游网站
查询一些目的地
记录在cookie中
等到下次访问时，网站会自动根据我们查询过的关键字，主动把一些用户关注的信息，放在显要位置或置前
提升用户体验
测试点
1.以某个用户登录
2.进行旅游地点的查询
查询1个
查询多个
是多个目的地都显示相关信息
还是只显示查询频率最高的目的地的信息
只显示最近一次查询目的地信息
开发或设计人员明确后才能确定
3.退出
4.重新登录
5.预期输出
针对用户查询过的旅游地点进行内容的自动提取和推送
开发沟通
系统是否提供这样的功能
统计网站用户经常查询的关键字有哪些，对这些关键字进行统计和排序
提取所有客户的cookie文件信息
旅游目的地的查询关键字
对关键字使用程序进行统计
或进行数据分析
进行排序
对于查询频率较高的地点
信心置顶
多搜索此类信息
提高网站的吸引力
去西藏，可能开发更多的关于西藏的内容，供用户查询、使用或购买
来提升网站的效益
用户经常性的购买某一类商品，在登录后，系统可以自动推送相关的内容
什么是session
为什么使用cookie？
1.方便用户进行登录
相关的用户信息存储在cookie文件中
2.收集用户的相关登录时间、时长、使用习惯等
为什么使用session？
1.登录网站后，进行各种操作
2.跳转到其他页面
http协议
无状态协议
不记录用户身份信息
产生的问题
1.只要打开一个新的页面，就需要操作登录进行身份验证
2.任意人就可以直接输入网址进行访问
查询高考的成绩
网页地址
不进行身份验证
直接输入网页地址就能打开页面
安全性差
3.产生了session技术处理
session原理
1.当用户注册后
2.在本地生成一个cookie文件，保存用户信息
3.用户登录
1.系统检查本地是否存在cookie文件
若不存在，等待登录成功后，在本地创建cookie文件
若已存在，系统在用户登录的同时，由服务器端自动随机分配一个sessionID传入cookie文件进行保存
4.当用户打开某些需要权限设置的页面时，系统回去检查对应的sessionID是否有效正确
5.假如服务器无法识别对应的sessionID或者不存在对应的sessionID
提示没有权限打开该页面，提示用户重新登录
6.若对应的sessionID存在且有效正确
展开对应用户的相关页面
查看自己的订单等
sessionID有一个有效期
一般30分钟，安全性高的10分钟
session测试点
用户登录系统时，服务器给发送随机的sessionID
页面跳转时进行身份的验证
测试前沟通准备工作
1.sessionID存在在哪里
2.session有效期
session有效期我们设置的时长
30.分钟
测试点
1.登录
2.系统会生成sessionID
3.在30分钟内打开相关页面
可以正常打开使用
4.超过30分钟没有进行任何操作
5.再打开有相关权限设置的页面
或在已打开的页面
查看订单页面
查看个人信息页面
执行刷新操作
预期输出
提示网页已过期，请重新登录
3.session内容更新的测试
4.sessionID互窜测试
每一个不同的用户登录
都会生成一个唯一的sessionID
测试点1
1.打开某一个浏览器
2.以张三登录
3.立刻退出浏览器
4.重新打开浏览器
5.以李四登录
6.再退出浏览器
7.直接打开某一个需要权限校验的页面
预期输出:？
开发沟通确认
设计是如何要求的
默认使用张三的账号
默认使用李四的账号
默认提示没有权限，请重新登录
针对session存放在cookie文件中
测试点2
1.打开某一个浏览器A
2.以张三登录
3.重新用浏览器A打开新的登录页面
4.在第二个页面中，以李四登录
5.又重新回到张三登录后的页面
6.进行相关的权限页面操作
查看个人信息
7.预期输出：显示张三的个人信息页面
多打开几个页面，用多个用户进行尝试
5个用户的测试
测试点3
1.打开某一个浏览器A
I.E.
2.以张三登录
3.打开另一个浏览器B
火狐
4.以李四登录
5.回到浏览器A
6.打开相关的张三权限页面
查看个人信息
7.预期输出：显示张三的个人信息页面
多使用多种不同的浏览器，进行多用户的尝试
用5种不容的浏览器产品，选择5个不同的用户进行测试
sessionID的安全性测试
测试点1
存储安全
临时内容中
是否可以通过内存访问工具获取
是否进行加密存储
存放在cookie文件中
一定要进行加密存储
测试点2
传输安全
登录提交后
post
get
将sessionID 传给服务器
传送过程中是否进行加密
抓包工具。截取数据包，如果没有加密，就可能会被获取或篡改
sessionID性能测试
原因，session是从服务器发出的
会对服务器的性能造成压力
多人同时并发登录时
服务器要进行session的处理和分配
作业
cookie
cookie的原理和作用
cookie测试点
cookie的缺点
session
session的作用
session的测试点
cookie与session的区别：
Session和Cookies区别cookie数据存放在客户的浏览器上，session数据放在服务器上。cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用COOKIE。单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
作业
知道cookie和session的关系
知道cookie是如何产生的
知道sessionid的产生和作用
知道cookie上的重要字段和作用
常见的状态码及含义
常用的HTTP(网站数据按照http协议传输)状态码如下：
服务器处理浏览器请求后的结果如下：
- 成功的状态码：
2. 200 – 服务器成功返回网页
3. 304 – 未修改
- 失败的状态码：
5. 404 – 请求的网页不存在
6. 503 – 服务器暂时不可用
7. 500 – 服务器内部错误
下面的不是很常用，记住上面那几个就ok了，有bug了再补充
其他的状态码如下：
1xx（临时响应）
用于表示临时响应并需要请求者执行操作才能继续的状态代码。
1. 100（Continue继续） 请求者应当继续提出请求。服务器返回此代码则意味着，服务器已收到了请求的第一部分，现正在等待接收其余部分。（HTTP 1.1新）
2. 101（Switching Protocols切换协议） 请求者已要求服务器切换协议，服务器已确认并准备进行切换。（HTTP 1.1新）
2xx（成功）
用于表示服务器已成功处理了请求的状态代码。
1. 200（成功） 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。
2. 201（已创建） 请求成功且服务器已创建了新的资源。
3. 202（已接受） 服务器已接受了请求，但尚未对其进行处理。
4. 203（非授权信息） 服务器已成功处理了请求，但返回了可能来自另一来源的信息。
5. 204（无内容） 服务器成功处理了请求，但未返回任何内容。
6. 205（重置内容） 服务器成功处理了请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如清除表单内容以输入新内容）。
7. 206（部分内容） 服务器成功处理了部分 GET 请求。
3xx（已重定向）
要完成请求，您需要进一步进行操作。通常，这些状态代码是永远重定向的。Google 建议每次请求时使用的重定向要少于 5 个。
1. 300（多种选择） 服务器根据请求可执行多种操作。服务器可根据请求者 (User agent) 来选择一项操作，或提供操作列表供请求者选择。
2. 301（永久移动） 请求的网页已被永久移动到新位置。服务器返回此响应（作为对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。您应使用此代码通知 Googlebot 某个网页或网站已被永久移动到新位置。
3. 302（临时移动） 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。
4. 303（查看其他位置） 当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。
5. 304（未修改） 自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。
6. 305（使用代理） 请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
7. 307（临时重定向） 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。
4xx（请求错误）
这些状态代码表示，请求可能出错，已妨碍了服务器对请求的处理。
1. 400（错误请求） 服务器不理解请求的语法。
2. 401（未授权） 请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。
3. 403（已禁止） 服务器拒绝请求。
4. 404（未找到） 服务器找不到请求的网页。例如，如果请求是针对服务器上不存在的网页进行的，那么，服务器通常会返回此代码。
5. 405（方法禁用） 禁用请求中所指定的方法。
6. 406（不接受） 无法使用请求的内容特性来响应请求的网页。
7. 407（需要代理授权） 此状态代码与 401（未授权）类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
8. 408（请求超时） 服务器等候请求时超时。
9. 409（冲突） 服务器在完成请求时发生冲突。服务器必须包含有关响应中所发生的冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。
10. 410（已删除） 如果请求的资源已被永久删除，那么，服务器会返回此响应。该代码与 404（未找到）代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已被永久删除，那么，您应当使用 301 代码指定该资源的新位置。
11. 411（需要有效长度） 服务器不会接受包含无效内容长度标头字段的请求。
12. 412（未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
13. 413（请求实体过大） 服务器无法处理请求，因为请求实体过大，已超出服务器的处理能力。
14. 414（请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法进行处理。
15. 415（不支持的媒体类型） 请求的格式不受请求页面的支持。
16. 416（请求范围不符合要求） 如果请求是针对网页的无效范围进行的，那么，服务器会返回此状态代码。
17. 417（未满足期望值） 服务器未满足”期望”请求标头字段的要求。
5xx（服务器错误）
这些状态代码表示，服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。
1. 500（服务器内部错误） 服务器遇到错误，无法完成请求。
2. 501（尚未实施） 服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。
3. 502（错误网关） 服务器作为网关或代理，从上游服务器收到了无效的响应。
4. 503（服务不可用） 目前无法使用服务器（由于超载或进行停机维护）。通常，这只是一种暂时的状态。
5. 504（网关超时） 服务器作为网关或代理，未及时从上游服务器接收请求。
6. 505（HTTP 版本不受支持） 服务器不支持请求中所使用的 HTTP 协议版本。
状态码类别：
1xx：信息类，表示客户发送的请求服务端正在处理
2xx：成功类，服务器 成功接收请求
3xx：重定向类，服务器中找到了多个请求内容，则需要用户再次操作选择
4xx：客户端错误类，对于发的请求服务器无法处理
5xx：服务器错误类，由于服务器发生故障或遇到错误无法回应
常见的状态码：
1xx：信息类
100：继续发送请求，客户端之前发送的请求服务器未拒绝。服务器必须在客户端发送完请求后才能发送一个回应
101：服务器接收客户请求，将其转化成另一种协议来处理
2xx：成功类
200：服务器成功处理请求
202：服务器接受了客户端的请求，还在处理中
204：服务器处理了请求，但是没有新的内容生成。刷新页面后页面还是保持原来的，不会改变
205：和204有点相似，也是服务器处理了请求，但是没有新的内容生成。但是刷新页面后浏览器会清除内容，重新显示内容
206：客户端发送范围请求，服务器处理完成
3xx：重定向类
301：永久重定向。例如：请求https：//localhost/index时服务器返回301，就会给url末尾加个“/”。则最终访问的url是：https：//localhost/index/
302：临时性重定向。和301说明类似
304：客户端发送请求后，服务器允许访问，但是浏览器中缓存的内容还在有效期中，这时返回状态码为304
307：http1.1中新增。将请求分为get和post，他的重定向只对于get请求
4xx：客户端错误类
400：请求的内容中存在语法错误
401：说明访问的请求受保护。需要用户认证
403: 服务器接受客户端发出的请求，但是拒绝处理。例如访问服务器中有些未被授权的内容
404：服务器找不到请求的内容
405:用来访问本页面的HTTP谓词不被允许（方法不被允许）
407：需要代理身份才能进行访问，即客户端访问需要通过代理授权
414：请求的url太长
5xx：服务器错误类
500：服务器遇到了某些情况，处理请求失败。笔者遇到过接口崩掉时请求返回状态码为500
502: bad gateway，网关错误。如果一直提示怎可能是ip设置的时候网关地址错误，偶尔出现可能是网关的上一级错误
503：服务器在维护或者负载过重不能处理客户端发出的请求
505：服务器不支持请求中的http版本
本文使用 文章同步助手 同步
