《图解http》笔记

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

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

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

2、负责传输的IP协议

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

3、确保可靠性的TCP协议

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

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

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

5、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协议

1、报文组成：

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

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

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

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

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

4、持久连接节省通信量

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）方式发送成为可能。从前发送请求后需要等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样胖就能够做到同时并行发送多个请求，而不需要一个接一个的等待响应。

5、使用Cookie的状态管理

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

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

1、HTTP报文

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

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

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

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

首部组成：

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

• 状态行：包含表明响应结果状态码，原因短语和HTTP版本

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

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

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

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

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

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

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

1、2** 成功

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

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

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

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

2、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状态码是最理想的。

当301、302、303响应状态码返回时，几乎所有的浏览器都会把POST改成GET，并删除请求报文内的主体，之后请求会自动再次发送。301、302标准是禁止将POST方法改成GET方法的，但实际会用时大家都这么做。

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

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

3、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首部

1、HTTP报文首部

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

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

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

2、4种HTTP首部字段类型

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

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

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

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

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

第七章 确保Web安全的HTTPS

1、HTTP的缺点

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

2、通信使用明文可能会被窃听

由于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、无法证明报文完整性，可能已遭篡改

所谓完整性是指信息的准确性。若无法证明其完整性，通常也就意味着无法判断信息是否准确。
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）函数计算出散列值后保存。但是我们也经常看到直接保存明文密码的做法，而这样的做法具有导致密码泄漏的风险。

文章知识点与官方知识档案匹配，可进一步学习相关知识网络技能树跨区域网络的通信学习网络层的作用22388 人正在系统学习中 相关资源：Veneer:文件屏蔽软件-开源-其它代码类资源-CSDN文库

来源：weixin_34082177