《图解http》笔记

第1章、了解Web几网络基础

一、TCP/IP协议族按层次分别分为如下4层：

应用层： 应用层决定了向用户提供应用服务时通讯的活动。例如：FTP（文件传输协议）、DNS（域名系统）、http
传输层： 传输层对上层应用层，提供处于网络链接中的两台计算机之间的数据传输。协议：TCP（传输控制协议）、UDP（用户数据报协议）
网络层（又名网络互联层）： 网络层用来处理网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了经过怎样的路径（所谓的传输线路）到达对方计算机，并把数据包传送给对方。
与对方计算机之间经过多台计算机或玩过设备进行传输时，网络层所起的做用就是在众多的选项内选择一条传输路线。协议： IP协议
链路层（又名数据链路层，网络接口层）：
用来处理链接网络的硬件部分。包括控制操做系统、硬件的设计驱动、NIC（网络适配器，即网卡），及光纤等物理可见部分（还包括链接器等一切传输媒介）。硬件上的范畴均在链路层的做用范围以内。

二、负责传输的IP协议

按层次分，IP（Internet Protocol）网际协议位于网络层。IP协议的做用是把各类数据包传送给对方。而要把保证确实传送到对方那里，则须要知足各种条件。其中两个最重要的条件就是IP地址和MAC地址。IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址能够和MAC地址进行配对。IP地址可变换，但MAC地址基本上不会更改。

三、确保可靠性的TCP协议

按层次分，TCP位于传输层，提供可靠的字节流服务。
所谓的字节流服务是指，为了方便传输，将大块数据分割成以报文段为单位的数据包进行管理。而可靠的传输服务是指可以把数据准确可靠的传给对方。一言蔽之，TCP协议为了更容易的传送大数据把数据分割，并且TCP协议可以确认数据最终是否送达到对方。 为了准确无误的将数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出去以后，TCP不会对传送后的状况置之不理，它必定会向对方确认是否成功送达。握手过程当中使用了TCP的标志（flag）---SYN（synchronize）和ACK（ackonwledgement）。 发送端首先发送一个带SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后，发送端在回传一个带ACK标志的数据包，表明“握手”结束。 若在握手过程当中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

四、负责域名解析的DNS服务

DNS（Domain Name System）服务时和HTTP协议同样位于应用层的协议。他提供域名到IP地址之间的解析服务。
计算机既能够被赋予IP地址，也恶意被赋予主机名和域名。好比www.hackr.jp。
用户一般使用主机名或域名来访问对方的计算机，而不是直接经过IP地址访问。由于与IP地址的一组纯数字相比，用字幕配合数字的表示形式来指定计算机名更符合人类的记忆习惯。
但要让计算机去理解名称，相对而言就变得困难了。由于计算机更擅长处理一长串数字。
为了解决上述的问题，DNS服务应运而生。DNS协议提供经过域名查找IP地址，或逆向从IP地址反查域名的服务。

五、URI和URL

URI（统一资源标识符）用字符串标识某一互联网资源，而URL（统一资源定位符）标识资源的地点（互联网上所处的位置）。
URI格式： user:pass@www.example.jp:80/dir/index.h…
使用http：或者https:等协议方案名获取访问资源时要指定协议类型。不区分字母大小写，最后附一个冒号（：）。
也可使用data：或javascrip：这类指定数据或脚本程序的方案名。

• 登陆信息（认证）：指定用户名和密码做为从服务器获取资源时必要的登陆信息（身份认证）。此项是可选项。
• 服务器地址：使用绝对URI必须指定待访问的服务器地址。地址能够是相似hackr.jp这种DNS能够解析的名称，或是192.168.1.1这类IPv4地址名，还能够是[0:0:0:0:0:0:0:1]这样用方括号括起来的IPv6地址名。
• 服务器端口号：指定服务器链接的网络端口号。此项也是可选项，若用户省略则自动使用默认端口号。
• 带层次的文件路径：指定服务器上的文件路径来定位特指的资源。这与UNIX系统的文件目录结构类似。
• 查询字符串：针对已指定的文件路径内的资源，可使用字符串传入任意参数。此项可选。
• 片断标识符：使用片断标识符一般可标记处已获取资源中的子资源（文档内的某个位置）。但在RFC中并无明确规定其使用方法。该项也为可选项。（并非全部的应用程序都会符合RFC）

第二章、简单的HTTP协议

一、报文组成：

请求报文组成：请求方法、请求URI、协议版本、可选的请求首部字段和内容实体
响应报文组成：协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的缘由短语、可选的响应首部字段以及实体主体

二、HTTP是不保存状态的协议

HTTP是一种不保存装填，即无状态（stateless）协议。HTTP协议自己不对请求和响应之间的通讯状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不作持久化处理。
HTTP/1.1虽然是无状态协议，但为了实现指望的保持状态功能，因而引入了Cookie技术。

三、告知服务器意图的HTTP方法

• GET:获取资源
• POST：传输实体主体
• PUT：传输文件
• HEAD：获取报文首部
• DELETE：删除文件
• OPTIONS：询问支持的方法
• TRACE：追踪路径
• CONNECT：要求用隧道协议链接代理

四、持久链接节省通讯量

HTTP协议的初始版本中，每进行一次HTTP通讯就要断开一次TCP链接。为解决TCP链接的问题，HTTP/1.1和一部分的HTTP/1.0想出了持久链接（HTTP Persistent Connects，也成为HTTP keep-alive或HTTP connection reuse）的方法。持久链接的特色是，只要任意一端没有明确提出断开了解，则保持TCP链接状态。
持久链接的好处在于减小了TCP链接的重复创建和断开所形成的额外开销，减轻了服务器端的负载。另外，减小开销的那部分时间，使HTTP请求和相应可以更早的结束，这样Web页面的显示速度也就提升了。
在HTTP/1.1中，全部的链接默认都是持久链接，但在HTTP/1.0内并未标准化。虽然有一部分服务器经过非标准的手段实现了持久链接，但服务器端不必定可以支持持久链接。毫无疑问，除了服务器端，客户端也须要支持持久链接。
管线化：持久链接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后须要等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样胖就可以作到同时并行发送多个请求，而不须要一个接一个的等待响应。

五、使用Cookie的状态管理

不能否认，无状态协议固然有他的有点。因为没必要保存状态，天然可减小服务器的CPU几内存资源的消耗。从另外一侧面来讲，也正是由于HTTP协议自己是很是简单的，因此才会被应用在各类场景里。
保留无状态协议这个特征的同事又要解决让服务期管理所有客户端状态则会成为负担的矛盾问题，因而引入了Cookie技术。Cookie结束经过在请求和响应报文中写入Cookie信息来控制客户端的状态。
Cookie会根据从服务器端发送的响应报文内的一个叫作Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。
服务器端发现客户端发送过来的Cookie后，回去检查到底是从哪个客户端发来的链接请求，而后对比服务器上的记录，最后获得以前的状态信息。

第三章、HTTP报文内的HTTP信息

一、HTTP报文

用于HTTP协议交互的信息叫作HTTP报文。请求端（客户端）的HTTP报文叫作请求报文，响应端（服务端）的叫作响应报文。HTTP报文自己由多行（用CR+LF作换行符）数据构成的字符串文本。
HTTP报文大体可分为报文首部和报文主体两块。二者由最初出现的空行来划分。一般，并不必定要有报文主体

二、请求报文及响应报文的结构

• 请求报文首部：请求行、请求首部字段、通用首部字段、实体首部字段、其余

• 响应报文首部：状态行、响应首部字段、通用首部字段、实体首部字段、其余

首部组成：

• 请求行：包含用于请求的方法，请求URI和HTTP版本

• 状态行：包含代表响应结果状态码，缘由短语和HTTP版本

• 首部字段：包含表示请求和响应的各类条件和属性的各种首部。通常包含四种：分别是：通用首部、请求首部、响应首部、和实体首部

• 其余：可能包含HTTP的RFC里未定义的首部（Cookie等）

三、发送多种数据的多部分对象集合

发送邮件时，咱们能够在邮件里写入文字并添加多分附件。这是由于采用了MIME（Multipurpose Internet Mail Extensions,多用途因特网邮件扩展）机制，它容许邮件处理文本、图片、视频等多个不一样类型的数据。例如，图片等二进制数据以ASCII码字符串编码的方式指明，就是利用MIME来标记数据类型。而在MIME扩展中会使用一种称为多部分对象集合（Multipart）的方法，来容纳多份不一样类型的数据。
相应的，HTTP协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。一般是在图片或文本文件等上传时使用。

多部分对应集合包含的对象以下。

• multipart/form-data:在Web表单文件上传时使用
• multipart/byteranges:状态码206（Partial Content，部份内容）响应报文包含了多个范围的内容时使用

第四章 返回结果的HTTP状态码

一、2** 成功

2** 的响应结果代表请求被正常处理了。

• 200 OK 表示从客户端发来的请求在服务器端被正常处理了。 在响应报文内，随状态码一块儿返回的信息会由于方法的不一样而发生改变。好比，使用GET方法时，对应请求资源的实体会做为响应返回；而使用HEAD方法时，对应请求资源的实体首部不随报文主体做为响应返回（即在响应中只返回首部，不会返回实体的主体部分）

• 204 No Centent 该状态码表明服务器接收的请求已成功处理，但在返回的响应报文中不包含实体的主体部分，另外，也不容许返回任何实体的主体。好比，当从浏览器发出请求处理后，返回204响应，那么浏览器显示的页面不会发生更新。
  通常在只须要从客户端往服务器发送信息，而对客户端不须要发送信息新内容的状况下使用。

• 206 Partical Content 该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。

二、3** 重定向

3**响应结果代表浏览器须要执行某些特殊的处理以正确处理请求。

• 301 Moved Permanently 永久性重定向。该状态码表示请求的资源已被分配了新的URI，之后应使用资源如今所指的URI。也就是说，若是已经把资源对应的URI保存为书签了，这时应该按Location首部字段提示的URI从新保存。
  像下方给出的请求URI，当指定资源路径的最后忘记添加斜杠“/”,就会产生301状态码
  example.com/sample

• 302 Found 临时性重定向。该状态码表示请求的资源已被从新分配了新的URI，但愿用户（本次）能使用新的URI访问。
  和301 Moved Permanently状态码类似，但302状态码表明的资源不是被永久移动，只是临时性性质的。换句话说，已移动的资源对应的URI未来还有可能发生改变。好比，用户把URI保存成书签，但不会像301状态码出现时那样去更新书签，而是仍旧保留返回302状态码的页面对应的URI。

• 303 See Other 该状态码表示因为请求对应的资源存在着另外一个URI，应使用GET方法定向获取请求的资源。
  303状态码和302Found状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。
  好比，当使用POST方法访问CGI程序，其执行后的处理结果是但愿客户端能以GET方法重定向到另外一个URI上去时，返回303状态码。虽然302Found状态码也能够实现相同的功能，但这里使用303状态码是最理想的。

当30一、30二、303响应状态码返回时，几乎全部的浏览器都会把POST改为GET，并删除请求报文内的主体，以后请求会自动再次发送。30一、302标准是禁止将POST方法改为GET方法的，但实际会用时你们都这么作。

• 304 Not Modified 该状态码表示客户端发送附带条件的请求时，服务器端容许请求访问资源，但因发生请求未知足条件的状况后，直接返回304Not Modified（服务器资源未发生改变，可直接使用客户端未过时的缓存）。304状态码返回时，不包含任何响应的主体部分。304虽然被划分在3**类别中，可是和重定向没有关系。

• 307 Temporary Redirect 临时重定向。该状态码与302Found有着相同的含义。尽管302标准禁止POST变换成GET，但实际使用时你们并不遵照。
  307会遵守浏览器标准，不会POST变成GET。可是，对于处理响应时的行为，每种浏览器有可能会出现不一样的状况。

三、4** 客户端错误

4**的响应结果代表客户端是发生错误的缘由所在。

• 400 Bad Request 该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像200 OK同样对待该状态码。

• 401 Unauthorized 该状态码表示发送的请求须要有经过HTTP认证（BASIC认证DIGEST认证）的认证信息。另外若以前已进行过1次请求，则表示用户认证失败。
  返回含有401的响应必须包含一个适用于被请求资源的WWW-Authenticate首部用以质询（challenge）用户信息。当浏览器初次接受到401响应，会弹出认证用的对话窗口。

• 403 Forbidden 该状态码代表对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但若是想做说明的话，能够在实体的主体部分对缘由进行描述，这样就能让用户看到了。
  未得到文件系统的访问受权，访问权限出现某些问题（从未受权的发送源IP地址试图访问）等列举的状况均可能是发生403的缘由。

• 404 Not Found 该状态码代表服务器上没法找到请求的资源。除此以外，也能够在服务器端拒绝请求切不想说明理由时使用。

5** 服务器错误

5** 的响应结果代表服务器自己发生错误。

• 500 Internal Server Error 该状态码代表服务器端在执行请求时发生了错误。也有多是Web应用存在的bug或某些临时的故障。

• 503 Service Unavailable 该状态码代表服务器暂时处于超负荷或正在进行停机维护，如今没法处理请求。若是实现得知解除以上状况须要的时间，最好写入Retry-After首部字段在返回给客户端。

第六章 HTTP首部

一、HTTP报文首部

HTTP报文组成：报文首部、空行（CR+LF）、报文主体。
HTTP协议的请求和响应报文中一定包含HTTP首部。首部内容为客户端和服务器端分别处理请求和响应提供所须要的信息。对于客户端用户来讲，这些信息中的大部份内容都无需亲自查看。
报文首部由几个字段构成。

• HTTP请求报文 在请求报文中，HTTP报文首部由方法、URI、HTTP版本、HTTP首部字段等部分构成。

• HTTP响应报文 在响应中，HTTP报文首部由HTTP版本、状态码（数字和缘由短语）、HTTP首部字段3部分构成。

二、4种HTTP首部字段类型

HTTP首部字段根据实际用途被分为如下四种类型

• 通用首部字段（General Header Fields） 请求报文和响应报文两方都会使用的首部。

• 请求首部字段（Request Header Fields） 从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

• 响应首部字段（Response Header Fields） 从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会使用客户端附加额外的内容信息。

• 实体首部字段（Entity Header Fields） 针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

第七章 确保Web安全的HTTPS

一、HTTP的缺点

• 通讯使用明文（不加密），内容可能会被窃听
• 不验证通讯方的身份，所以有可能遭遇假装
• 没法证实报文的完整性，因此有可能已遭篡改

二、通讯使用明文可能会被窃听

因为HTTP自己不具有加密的功能，因此也没法作到对通讯总体（使用HTTP协议通讯的请求和响应的内容）进行加密。即，HTTP报文使用明文（指未通过加密的报文）方式发送。

2.1 TCP/IP是可能被窃听的网络
若是要问问什么通讯时不加密是一个缺点，这是由于，按TCP/IP协议族的工做机制，通讯内容在全部的通讯线路上都有可能遭到窥视。
所谓互联网，是由能连通到全世界的网络组成的。不管世界哪一个角落的服务器在和客户端通讯时，在此不排除某个环节中会遭到窥视行为。
即便已通过加密处理的通讯，也会被窥视到通讯内容，这点和未加密的通讯时相同的。只是说若是通讯通过加密，就有可能让人没法破解报文信息的含义，但加密处理后的报文信息自己仍是会被看到的。

2.2 加密处理防止被窃听

• 通讯的加密 一种方式就是将通讯加密。HTTP协议中没有加密机制，但能够经过和SSL（Secure Socket Layer，安全套阶层）或TLS（Transport Layer Security，安全传输层协议）的组合使用，加密HTTP的通讯内容。
  用SSL创建安全通讯线路以后，就能够在这条线路上进行HTTP通讯了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure,超文本传输安全协议）或HTTP over SSL。

• 内容的加密 还有一种将参与通讯内容自己的加密方式。因为HTTP协议中没有加密机制，那么就对HTTP协议传输的内容自己加密。即把HTTP报文里所含的内容进行加密处理。
  在这种状况下，客户端须要对HTTP报文进行加密处理后在发送请求。
  诚然，为了作到有效的内容加密，前提是要求客户端和服务器同事具有加密和解密机制。主要应用在Web服务中。有一点必须引发注意，因为该方式不一样于SSL或TLS将整个通讯线路加密处理，因此内容仍有被篡改的风险。

3不验证通讯方的身份就可能遭遇假装

HTTP协议中的请求和响应不会对通讯方进行确认。也就是说存在“服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端”等相似问题。
3.1 任何人均可以发起请求
在HTTP协议通讯时，因为不存在确认通讯方的处理步骤，任何人均可以发送请求。另外，服务器只要接收到请求，无论对方是谁都会返回一个响应（但也仅限于发送端的IP地址和端口号没有被Web服务器设定访问限制的前提下）。
HTTP协议的实现自己很是简单，不管是谁发送过来的请求都会返回响应，所以不确认通讯方，会存在如下各类隐患：

• 没法肯定请求发送至目标的Web服务器是不是按真实意图返回响应的那台服务器。有多是已假装的Web服务器。
• 没法肯定响应返回到的客户端是不是按真实意图接收响应的那个客户端。有多是已假装的客户端。
• 没法肯定正在通讯的双方是否具有访问权限。由于某些Web服务器上保存着重要的的信息，只想发给特定用户通讯的权限。
• 没法断定请求是来自何方，出自谁手
• 即便是无心义的请求也会照单全收。没法阻止海量请求下的DoS攻击（Denial of Service，拒绝服务攻击）。

3.2 查找对手的证书 虽然使用HTTP协议没法肯定通讯方，但若是使用SSL则能够。SSL不只提供加密处理，并且还使用了一种被称为证书的手段，可用于肯定方。
证书由指的新人的第三方机构颁发，用以证实服务器和客户端是实际存在的。另外，伪造证书从技术角度来讲是异常困难的一件事。因此只要可以确认通讯方（服务器或客户端）持有的证书，便可判断通讯方的真实意图。
经过使用证书，以证实通讯方就是意料中的服务器。这对使用者我的来说，也减小了我的信息泄露的危险性。
另外，客户端持有证书便可完成我的身份的确认，也可用Web网站的认证环节。

四、没法证实报文完整性，可能已遭篡改

所谓完整性是指信息的准确性。若没法证实其完整性，一般也就意味着没法判断信息是否准确。
4.1接收到的内容可能有误
因为HTTP协议没法证实通讯的报文完整性，所以，在请求或响应送出以后知道对方接收以前的这段时间内，即便请求或响应的内容遭到篡改，也没有办法获悉。
换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应时先后相同的。
如何防止篡改
虽然有使用HTTP协议肯定报文完整性的方法，但事实上并不便捷、可靠。其中经常使用的是MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法。

5 HTTPS采用混合加密机制

HTTPS采用共享密钥加密和公开密钥加密二者并用的混合加密机制。若密钥可以实现安全交换，那么有可能胡考虑仅使用公开密钥加密来通讯。可是公开密钥加密与共享密钥加密相比，其处理速度更慢。
因此应充分利用二者各自的优点，将多种方法组合起来用于通讯。在交换密钥环节使用公开密钥加密方式，以后的简历通讯交换报文阶段则使用共享密钥加密方式。

6 HTTPS的安全通讯机制

• 步骤1：客户端经过发送Client Hello报文开始SSL通讯。报文中包含客户端支持的SSL的指定版本、加密组织（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
• 步骤2：服务器可进行SSL通讯时，会以Server Hello报文做为应答。和客户端同样，在报文中包含SSL版本以及加密组件。服务器的加密组织内容是从接收到的客户端加密组件筛选出来的。
• 步骤3：以后服务器发送Certificate报文。报文中包含公开密钥证书。
• 步骤4：最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
• 步骤5：SSL第一次握手结束以后，客户端以Client Key Exchange报文做为响应。报文中包含通讯加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
• 步骤6:接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此安博文以后的通讯会采用Pre-master secret密钥加密。
• 步骤7：客户端发送Finished报文。该报文包含链接至今所有报文的总体校验值。此次握手协商是否可以成功，要以服务器是否可以正确解密该报文做为断定标准。
• 步骤8：服务器一样发送Change Cipher Spec报文。
• 步骤9：服务器一样发送Finished报文。
• 步骤10：服务器和客户端的Finished报文交换完毕以后，SSL链接就算创建完成。固然，通讯会收到SSL的保护。今后处开始进行应用层协议的通讯，即发送HTTP请求。
• 步骤11：应用层协议通讯，即发送HTTP响应。
• 步骤12：最后由客户端断开链接。断开链接时，发送close_notify报文。这步以后再发送TCP FIN报文来关闭与TCP的通讯。

7 SSL变慢缘由

HTTPS也存在一些问题，那就是使用SSL时，他的处理速度会变慢。
SSL的慢分两种。一种是指通讯慢。另外一种是指因为大量消耗CPU及内存等资源，致使处理速度变慢。
和使用HTTP相比，网络负载可能会变慢2-100倍。除去和TCP链接、发送HTTP请求·响应意外，还必须进行SSL通讯，所以总体处理通讯量不可避免会增长。
另外一是SSL必须进行加密处理。在服务器和客户端都须要进行加密和解密的运算处理。所以从结果上讲，比起HTTP会更多的消耗服务器和客户端的硬件资源，致使负载增长。
针对速度变慢这一问题，并无根本性的解决方法，咱们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通讯专用硬件，相对软件来说，可以提升数倍SSL的计算速度。尽在处理SSL时发挥SSL加速器的功效，以分担负载。

第八章 确认访问用户身份的认证

1 Session管理及Cookie应用

基于表单认证的标准规范还没有有定论，通常会用Cookie来管理Session（会话）。
基于表单认证自己是经过服务器端的Web应用，将客户端发送过来的用户ID和密码与以前登陆过的信息作匹配来进行认证的。
但鉴于HTTP是无状态协议，以前已认证成功的用户状态没法经过协议层面保存下来。即，没法实现状态管理，所以即便当该用户下一次继续访问，也没法区分他与其余的用户。因而咱们会使用Cookie在管理Session，以弥补HTTP协议中不存在的状态管理功能。

• 步骤1：客户端把用户ID和密码等登陆信息放入报文的实体部分，一般是以POST方法把请求发送给服务器。而这时，会使用HTTPS通讯来进行HTML表单画面的显示和用户输入数据的发送。

• 步骤2：服务器会发送用以识别用户的Session ID。经过验证从客户端发送过来的登陆信息进行身份认证，而后把用户的认证状态与Session ID绑定后记录在服务器端。
  向客户端返回响应时，会在首部字段Set-Cookie内写入Session ID（如PHPSESSID=028a8c···）。
  你能够把Session ID想象成一种用以区分不用用户的等位号。然而，若是Session ID被第三方盗走，对方就能够假装成你的身份进行恶意操做了。所以必须防止Session ID被盗，或被猜出。为了作到这点，Session ID应使用难以推测的字符串，且服务器端也须要进行有效的管理，保证其安全性。
  另外，为减轻跨站脚本攻击（XSS）形成的损失，建议事先将Cookie内加上httponly属性。

• 步骤3：客户单接受从服务器端发来的Session ID后，会将其做为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，因此Session ID也随之发送到服务器。服务器可经过验证接收到的Session ID识别用户和其认证状态。

除了以上介绍的应用实例，还有应用其余不一样方法的案例。 另外，不只基于表单认证的登陆信息及认证过程都无表转化的方法，服务器端应如何保存用户提交的密码等登陆信息等也没有标准化。 一般，一种安全的保存方法是，先利用给密码加盐（salt）的方式增长额外信息，在使用散列（hash）函数计算出散列值后保存。可是咱们也常常看到直接保存明文密码的作法，而这样的作法具备致使密码泄漏的风险。