iOS 网络知识

iOS 网络相关

一、http协议

• 1、描述
  是一种详细规定了浏览器和万维网服务器之间互相通信的规则，是传送万维网文档的数据传送协议。http是基于tcp的应用层协议。
  

• 2、请求报文
  

//例如
//请求行：
POST link/test.html HTTP/1.1
//请求头部：
Host：www.user.com//表明该对象所在的主机
Content-Type:application/x-www-form-urlencoded//内容类型
Connection:Keep-Alive//告诉服务器使用持续连接
User-agent:Mozilla/5.0//用户代理，即向服务器发送请求的浏览器类型
Accept-language:fr//表示用户想得到指定语言的版本（这里是法语）
//空行
...
//请求体
...

• 3、响应报文
  

//例如
//状态行
Http/1.1 200 OK//请求成功
//响应头部
Connection：close告诉客户端，发送完数据报后将关闭tcp连接
Server：apache/2.2.2(contOS)//这里指明数据是由apache服务器返回的，类似请求报文中user-agent
Date:Sat, 31 Dec 2005 23:59:59 GMT//服务器检索到对象，插入到响应报文，并发送数据的时间
Content-Type:text/html//指明响应体中的数据类型，这里是html文本类型
Content-Length:122//响应数据的字节数
//空行
...
//响应体
...

• 4、请求方式：GET、POST、PUT、DELETE、HEAD、OPTIONS
  1、GET和POST的区别：
  从语法角度来看，最直观的就是
  a、GET的请求参数是以?分割拼接在URL后面，POST的请求参数是放在body中
  b、GET参数长度限制为2048个字节，POST的参数长度无限制
  c、GET的参数暴露在URL中，POST的参数在body中，POST相对GET安全；之所以说相对安全，是因为POST的参数虽然非明文，但是被捉包，POST和GET一样不安全
  从语义上看
  a、GET：获取资源是安全的、幂等的（纯粹只读）、可缓存的
  b、POST：获取资源是不安全的、非幂等的、不可缓存的
  解析：
  安全：是指不应引起Server状态的变化；GET是获取数据，不引起Server的状态变化，是安全的（HEAD、OPTIONS也是安全）；POST是提交数据，是可能会引起Server状态变化的，是不安全的。
  幂等：多次请求和执行一次的结果是一样的
  可缓存：是否可缓存，GET请求是主动缓存的
  《补充： GET和POST的本质都是tcp连接，由于http的规定和浏览器/服务器的限制，使得他们在应用上不同；GET产生一个tcp数据包，POST产生两个tcp数据包；对于GET请求，浏览器会把header和实体一并发过去，服务器响应200（返回数据）；对于POST请求，浏览先把header发过去，服务器响应100 continue，浏览器再次发送实体，服务器响应200（返回数据）》
  c、GET对比POST的最大优势是方便、可缓存、直接书写url、可添加至书签和历史记录

• 5、特点：无状态、持久连接
  1、无状态：协议对事物处理没有记忆能力，每次请求都是独立的，它执行的情况和结果与前面的请求和后面的请求没有直接的关系。请求的应答情况不受上次的影响，也不会影响下一次的应答情况。
  2、持久连接：
  a、非持久连接：每个连接处理一个请求-响应事务；非持久连接，tcp得在客户端和服务端分配tcp缓冲区，并维持tcp变量，严重增加服务器的负担。
  b、持久连接：每个链接可以处理多个请求-响应事务；服务器发出响应后继续让tcp打开着，同一对客户/服务后续的请求和响应可以在这个连接发送

• 6、判断持久连接结束
  a、Content-length：根据接收字节数是否达到content-length值
  b、Chunked（分块传输）：当选择分块传输的时候，响应头可以不包括Content-length字段，服务器会先回复一个不带数据的报文，然后开始传输若干数据块；若干数据块传输完成后，再回复一个空的数据，客户端收到空的数据块则知道接收完毕

二、https协议

• 1、https和http的区别
  https协议=http+ssl/tls协议
  ssl全称是secure sockets layer，是为网络通信提供安全和数据完整性的一种协议；tls的全称是transport layer security 传输层安全协议。https是安全的http

• 2、https连接流程：为了兼顾安全和效率，https传输过程涉及到三个密钥；服务端的公钥/私钥，用于非对称加密；客户端随机生成的密钥，用于对称加密。
  a、客户端访问https连接：客户端把安全协议版本号和支持的算法、随机数C发给服务端
  b、服务端发送证书给客户端：服务端接收到加密配件算法后，与自己支持的加密算法列表比对，如果不符合，断开连接；否则服务端会在加密算法列表中选择一种对称加密算法（如DES）、非对称加密算法（如RSA）和MAC算法发给客户端。服务端持有一对密钥对，用于非对称加密，自己持有私钥，公钥可发给任何人。在发送算法的同时还会把数字证书和服务端的随机数S发给客户端。
  c、客户端验证Server证书：验证server证书中的公钥，验证其合法性，如若不合法，https无法进行连接
  d、客户端组装会话密钥：如果公钥合法，客户端会利用公钥生成一个前主密钥，通过前主密码和随机数C、S组装会话密钥
  e、客户端将前主密钥加密发给服务端：使用非对称公钥加密前主密钥然后发送给服务端
  f、服务端使用私钥解密获得前主密钥
  g、服务端组装会话密钥：通过前主密码和随机数C、S组装会话密钥
  h、数据传输：双方使用对称加密的密钥对传输的数据进行加密解密
  总结：会话密钥=前主密钥+随机数S+随机数C

• 3、对称加密和非对称加密
  a、对称加密：用同一套密钥加密解密，如3DES、IDEA算法
  b、非对称加密：用公钥私钥加密解密的算法，如RSA、ECC

三、tcp协议

• 1、特点：面向连接、可靠传输、面向字节流、全双工服务
• 2、报文结构
  

**源端口和目的端口：**多路复用/分解来自上层或者送达上层应用的数据
**序列号：**tcp将数据看成无结构、有序的字节流；例如数据流是由100000个字节组成的文件，其mss是1000数据的首字节编号是0；tcp为该数据流构建100个报文，第一个报文序列号为0，第二个为1000，第三个为2000，以此类推
**确认号：**tcp是全双工服务，主机A在向主机B发送数据的同时，也可能在接受主机B发送过来的数据。确认号是主机A期望从主机B收到的下一个报文字节的序号
数据偏移首部长度：因为有选项字段，tcp首部长度是可变的，该字段表明首部的长度
URG：用于指示报文段里存在着被发送端的上层实体置为“紧急”的数据
ACK：用于指示确认字段的值是否有效
PSH：用于指示接收方应立即把数据送至上层应用
RST、SYN、FIN：用于连接建立和拆除

• 3、三次握手：称三步握手更合理
  a、第一步：客户端向服务端发送一个特殊的tcp报文，该报文没有应用层数据，首部SYN字段置1，因此该报文被称为SYN报文；另外客户端会随机生成一个序号并赋值至序列号client_isn中；客户端进去SYN_SEND状态
  b、第二步：收到SYN报文，服务端会为tcp分配缓冲区和变量，并向客户端发送无应用层数据报文，SYN置为1，确认号置为client_isn+1，服务端进入SYN_RCVD状态，等待客户端的确认报文
  c、第三步：收到SYNACK报文后，客户端也为tcp分配缓冲区和变量，并发送确认报文给服务端，因为连接已建立，该报文可以携带应用层数据一并发送，该报文SYN置为0；服务端收到报文后进入ESTABLISHED状态
  

• 4、四次挥手
  概述：参与tcp连接的两个进程中的任何一个都能终止该连接，当连接接受后，会释放掉分配的内存（缓存和变量）
  第一步：客户端的进程发出结束连接的指令，tcp会发送一个首部标志FIN为1的tcp报文，同时客户端进入FIN_WAIT_1状态，等待带有确认的tcp报文
  第二步：收到报文后，服务端发送带有确认的tcp报文，服务端tcp进入CLOSE_WAIT状态
  第三步：服务端发送带有FIN为1的终止报文，进入LAST_ACK状态，等待客户端的确认报文
  第四步：客户端收到服务端的终止报文，向服务端发送确认报文，进入TIME_WAIT状态；加入ACK丢失，TIME_WAIT使得重传确认报文，TIME_WAIT通常等待2MSL，经过等待后，连接关闭，释放客户端的所有缓存和变量；服务端收到确认报文后，也会关闭连接，然后释放掉所有缓存和变量
  

• 5、可靠数据传输
  概述：tcp是在ip服务上创建的一种可靠数据传输服务；tcp的可靠数据传输服务确认一个进程从其接受缓存中读取的数据流是无损坏、无间隔、无冗余、按序的数据流。即该字节流与连接的另一端发出的字节流完全相同。作为tcp接收方，有三个与发送和重传相关的主要事件。
  a、从上层应用接收数据，将数据封装到一个报文段中，并把报文段交付给 IP。每个报文段都包含一个序号 Seq，即该报文段第一个数据字节的字节流编号。如果定时器还没有为其他报文段而运行，则启动定时器(即不是每条报文段都会启动一个定时器，而是一共只启动一个定时器)，定时器的过期间隔是 TimeoutInterval是由 EstimatedRTT 和 DevRTT 计算得来的:TCP 的往返时间的估计与超时
  b、超时 TCP 通过重传引起超时的报文段来响应超时事件，然后重启定时器。 而发送端超时有两种情况：发送数据超时，接收端发送 ACK 超时。这两种情况都会导致发送端在 TimeoutInterval 内接收不到 ACK 确认报文段。
  1）如果是发送数据超时，直接重传即可。
  2）而如果是接收端发送 ACK 超时，这种情况接收端实际上已经接收到发送端的数据了。那么当发送 端超时重传时，接收端会丢弃重传的数据，同时再次发送 ACK。
  而如果在 TimeoutInterval 后接收到了 ACK，会收下 ACK，但不做任何处理；TCP 不会为没有数据的 ACK 超时重传
  以下两种情况：
  1）如果在发送两条或多条数据报文段都超时，那么只会重传序号最小的那个，并重启定时器。只要 其余报文段的 ACK 在新重启的定时器超时前到达，就不会重传。
  2）如果发送序号为 100 和 120 的两条数据报文段，序号 100 的 ACK 丢失，但收到了序号 120 的 ACK， 由于累积确认机制，可以得出接收方已经接收到了序号 100 的报文段，这种情况也不会去重传。
  c、接收到 ACK 用 TCP 状态变量 SendBase 指最早未被确认的字节的序号。则 SendBase - 1 指接收方已正确按序接收 到的数据的最后一个字节的序号。 当收到 ACK 确认报文段后，会将 ACK 的值 Y 与 SendBase 比较。TCP 采用累计确认的方法，所以 Y 确认来 字节编号在 Y 之前的所有字节都已经收到。如果 Y 比 SendBase 小，不用理会；而如果 Y 比 SendBase大，则该 ACK 是在确认一个或多个先前未被确认的报文段，因此要更新 SendBase 变量，如果当前还有未 被确认的报文段，TCP 还要重启定时器。 通过超时重传，能保证接收到的数据是无损坏、无冗余的数据流，但并不能保证按序。 而通过 TCP 滑动窗口，能够有效保证接收数据有序

• 6、流量控制
  概述：TCP 连接的双方主机都会为该 TCP 连接分配缓存和变量。当该 TCP 连接收到正确、按序的字节后，就将数 据放入接收缓存。上层的应用进程会从该缓存中读取数据，但不必是数据一到达就立即读取，因为此时应 用程序可能在做其他事务。而如果应用层读取数据相对缓慢，而发送方发送得太多、太快，发送的数据就 会很容易地使该连接的接收缓存溢出。 所以，TCP 为应用程序提供了流量控制服务（flow-control service），以消除发送方使接收方缓存溢出的可 能性。 流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。 作为全双工协议，TCP 会话的双方都各自维护一个发送窗口和一个接收窗口（receive window）的变量来提 供流量控制。而发送窗口的大小是由对方接收窗口来决定的，接收窗口用于给发送方一个指示–该接收方还 有多少可用的缓存空间。
  

a、发送窗口 发送方的发送缓存内的数据都可以被分为 4 类: 1）已发送，已收到 ACK 2）已发送，未收到 ACK 3）未发送，但允许发送 4）未发送，但不允许发送
则 2 和 3 属于发送窗口
发送窗口只有收到发送窗口内字节的 ACK 确认，才会移动发送窗口的左边界
b、接收窗口 接收方的缓存数据分为 3 类： 1）已接收 2）未接收但准备接收 3）未接收而且不准备接收
则2）属于接收窗口（这里的接收指接收数据并确认）
接收窗口只有在前面所有的报文段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到 后面字节的情况下，会先接收下来，接收窗口不会移动，并不对后续字节发送 ACK 确认报文，以此确 保发送端会对这些数据重传。
我们定义以下变量：
1）LastByteRead：接收方应用程序读取的数据流的最后一个字节编号。可以得知，这是接收缓存的起 点
2）LastByteRcvd：从网络中到达的并且已放入接收缓存中的数据流的最后一个自己的的编号。
可以得知：LastByteRcvd - LastByteRead <= RcvBuffer(接收缓存大小) 那么接收窗口 rwnd =RcvBuffer - （LastByteRcvd - LastByteRead） rwnd 是随时间动态变化的，如果 rwnd 为 0，则意味着接收缓存已经满了。 接收端在回复给发送端的 ACK 中会包含该 rwnd，发送端则会根据 ACK 中的接收窗口的值来控制发送窗口。
有一个问题，如果当发送 rwnd 为 0 的 ACK 后，发送端停止发送数据。等待一段时间后，接收方应用程序 读取了一部分数据，接收端可以继续接收数据，于是给发送端发送报文告诉发送端其接收窗口大小，但这 个报文不幸丢失了，我们知道，不含数据的 ACK 是不会超时重传的，于是就出现发送端等待接收端的 ACK 通知||接收端等待发送端发送数据的死锁状态。
为了处理这种问题，TCP 引入了持续计时器（Persistence timer），当发送端收到对方的 rwnd=0 的 ACK 通 知时，就启用该计时器，时间到则发送一个 1 字节的探测报文，对方会在此时回应自身的接收窗口大小， 如果结果仍未 0，则重设持续计时器，继续等待。

• 7、拥塞控制
  TCP 除了可靠传输服务外，另一个关键部分就是拥塞控制。 TCP 让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。
  可能有三个疑问： 1、TCP 发送方如何感知网络拥塞？ 2、TCP 发送方如何限制其向连接发送流量的速率？ 3、发送方感知到网络拥塞时，采用何种算法来改变其发送速率？
  这就是 TCP 的拥塞控制机制。 前边说到，TCP 连接的每一端都是由一个接收缓存、一个发送缓存和几个变量（LastByteRead、 LastByteRcvd、rwnd 等）组成。而运行在发送方的 TCP 拥塞控制机制会跟踪一个额外的变量，即拥塞 窗口 cwnd（congestion window）。它对一个 TCP 发送方能向网络中发送流量的速率进行了限制。 发送方中未被确认的数据量不会超过 cwnd 和 rwnd 的最小值:min(rwnd,cwnd)
  1）TCP 发送方如何感知网络拥塞？
  冗余 ACK（duplicate ACK）：就是再次确认某个报文段的 ACK，而发送方先前已经收到对该报文段的确认。 冗余 ACK 的产生原因： 1.当接收端接收到失序报文段时，即该报文段序号大于下一个期望的、按序的报文段，检测到数据流 中的间隔，即由报文段丢失，并不会对该报文段确认。TCP 不使用否定确认，所以不能向发送方发送 显式的否定确认，为了使接收方得知这一现象，会对上一个按序字节数据进行重复确认，这也就产生 了一个冗余 ACK。 2.因为发送方经常发送大量的报文段，如果其中一个报文段丢失，可能在定时器过期前，就会收到大 量的冗余 ACK。一旦收到 3 个冗余 ACK（3 个以下很可能是链路层的乱序引起的，无需处理），说明 在这个已被确认 3 次的报文段之后的报文段已经丢失，TCP 就会执行快速重传，即在该报文段的定时 器过期之前重传丢失的报文段。 将 TCP 发送方的丢包事件定义为：要么出现超时，要么收到来自接收方的 3 个冗余 ACK。 当出现过度的拥塞时，路由器的缓存会溢出，导致一个数据报被丢弃。丢弃的数据报接着会引起发送方的 丢包事件。那么此时，发送方就认为在发送方到接收方的路径上出现了网络拥塞。
  2）TCP 发送方如何限制其向连接发送流量的速率？
  当出现丢包事件时：应当降低 TCP 发送方的速率。当对先前未确认报文段的确认到达时，即接收到非冗余 ACK 时，应当增加发送方的速率。
  3）发送方感知到网络拥塞时，采用何种算法来改变其发送速率？
  即 TCP 拥塞控制算法（TCP congestion control algorithm） 包括三个主要部分：慢启动、拥塞避免、快速恢复，其中快速恢复并非是发送方必须的，慢启动和拥塞避 免则是 TCP 强制要求的
  ===（1）===慢启动 当一条 TCP 连接开始时，拥塞窗口 cwnd 的值通常置为一个 MSS 的较小值，这就使初始发送速率大约 为 MSS/RTT（RTT：往返时延，报文段从发出到对该报文段的确认被接收之间的时间量）。 而对 TCP 发送方来说，可用带宽可能比 MSS/RTT 大得多,TCP 发送方希望迅速找到可用带宽的数量。 因此，在慢启动状态，cwnd 以一个 MSS 的值开始并且每当收到一个非冗余 ACK 就增加一个 MSS。
  

最初 cwnd 值为 1MSS，发送一个报文段 M1。收到 M1 的确认后，cwnd 增加为 2MSS，这时可以发送两个 报文段 M2，M3。收到这两个报文段的确认后，cwnd 则增加为4MSS，可以发送四个报文段，以此类推…
因此，TCP 虽然发送速率起始慢，但在慢启动阶段以指数增长。 这种指数增长很显然不是无限制的，那么何时结束呢？ 如果出现丢包事件，TCP 发送方将 ssthresh（慢启动阈值）设置为 cwnd/2 ；发生由超时引起的丢包事件，并将 cwnd 重置为 1MSS，重启慢启动 ；当 TCP 发送方的 cwnd 值达到或超过 ssthresh，再继续翻倍显然不合适。这时将结束慢启动转移到 拥塞避免模式。；TCP 发送方检测到 3 个冗余 ACK，会结束慢启动，并快速重传，即在该报文段的定时器过期之前重传 丢失的报文段。且进入快速恢复状态。

• 8、拥塞避免
  一旦进入拥塞避免状态，cwnd 的值大约是上次遇到拥塞时的值的一半，即距离拥塞并不遥远。因此，TCP 无法每过一个 RTT 就将 cwnd 翻倍。而是每个 RTT 只增加 1MSS，即每收到一个非冗余 ACK，就将 cwnd 增加 1/cwnd。即假如此时 cwnd 为 10MSS，则每收到一个非冗余 ACK，cwnd 就增加 1/10MSS，在 10 个报文段都收 到确认后，拥塞窗口的值就增加了 1MSS。
  

那么何时结束拥塞避免的线性增长（每 RTT 1MSS）呢？ 和慢启动一样，如果出现丢包事件，TCP 发送方将 ssthresh（慢启动阈值）设置为 cwnd/2（加法增大， 乘法减小）；发生由超时引起的丢包事件，拥塞避免和慢启动处理的方式相同。即 TCP 发送方将 ssthresh（慢启 动阈值）设置为 cwnd/2，并将 cwnd 重置为 1MSS，重启慢启动 ；TCP 发送方检测到 3 个冗余 ACK，cwnd 为原来的一半加上 3MSS，进入快速恢复状态。

• 9、快速恢复
  快速恢复是由 3 个冗余 ACK 引起的。 在快速恢复中，对引起 TCP 进入快速恢复状态的缺失报文段，对收到的每个冗余 ACK，cwnd 增加 1 个 MSS。 最终，当对丢失报文段的一个 ACK 到达时，TCP 在降低 cwnd 后进入拥塞避免状态。 如果出现超时，和之前一样，即 TCP 发送方将 ssthresh（慢启动阈值）设置为 cwnd/2，并将 cwnd 重 置为 1MSS，重启慢启动 快速恢复并非是必须的。 TCP 的拥塞控制是：每个 RTT 内 cwnd 线性（加性增）增加 1MSS，然后出现 3 个冗余 ACK 事件时 cwnd 减 半（乘性减），因此 TCP 拥塞控制常被称为加性增，乘性减拥塞控制方式。

四、DNS服务器

• 1、类型：根DNS服务器、顶级DNS服务器、权威DNS服务器

• 2、解析过程
  

• 3、DNS记录和报文
  a、DNS记录：所有 DNS 服务器都存储了资源记录（Resource Record，RR），其提供了主机名到 IP 的映射。
  资源记录是一个包含以下字段的四元组： （Name，Value，Type，TTL） TTL 是该记录的生存时间，决定了资源记录应当从缓存中删除的时间。 Name 和 Value 的值取决于 Type(以下涉及的 foo,bar 均为伪变量)：
  1）Type = A，则 Name 是主机名，Value 使其对应的 IP 地址。这也是一个标准的主机名到 IP 地址的映射。 如(replay1.bar.foo.com,145.37.93.126,A)
  2）Type = NS，则 Name 是个域（如 foo.com），而 Value 是个知道如何获取该域中主机 IP 地址的权威 DNS 服务器的主机名，如(foo.com,dns.foo.com,NS)
  3）Type = CNAME,则 Name 是别名为 Name 的主机对应的规范主机名。该记录能够向查询的主机提供一个 主机名对应的规范主机名，如（foo.com,replay1.bar.foo.com,CNAME）
  4）Type = MX，则 Value 是个别名为 Name 的邮件服务器的规范主机名。如（foo.com,main.bar.foo.com,MX）
  b、DNS报文：
  

• 4、DNS解析安全问题
  a、DNS劫持：一种可能的域名劫持方式即黑客侵入了宽带路由器并对终端用户的本地 DNS 服务器进行篡改，指向黑客自 己伪造的本地 DNS 服务器，进而通过控制本地 DNS 服务器的逻辑返回错误的 IP 信息进行域名劫持。 另一方面，由于 DNS 解析主要是基于 UDP 协议，除了上述攻击行为外，攻击者还可以监听终端用户的域名 解析请求，并在本地 DNS 服务器返回正确结果之前将伪造的 DNS 解析响应传递给终端用户，进而控制终端 用户的域名访问行为。
  

b、缓存污染（DNS 污染）。 我们知道在接收到域名解析请求时，本地 DNS 服务器首先会查找缓存，如果缓存命中就会直接返回缓存结 果，不再进行递归 DNS 查询。这时候如果本地 DNS 服务器针对部分域名的缓存进行更改，比如将缓存结果 指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上。
c、如何解决 DNS 劫持？DNS 解析发生在 HTTP 协议之前，DNS 解析和 DNS 劫持和 HTTP 没有关系，DNS 协议使用的是 UDP 协议向服 务器的 53 端口进行请求。可以使用 HttpDNS 的方案：使用 HTTP 协议向 DNS 服务器的 80 端口进行请求,来规避 DNS 劫持 比如：http://119.29.29.29/d?dn=domain&ip=clientIp；在终端上，可以更换 DNS 服务器，不管手机还是电脑，都能手动配置 DNS

五、cookie

• 1、用户与服务器的交互
  概述：cookie主要用来记录用户状态，区分用户，状态保存在客户端；cookie 功能需要浏览器的支持。如果浏览器不支持 cookie（如大部分手机中的浏览器）或 者把 cookie 禁用了，cookie 功能就会失效。
  

• 2、cookie的修改和删除
  在修改 cookie 的时候，只需要新 cookie 覆盖旧 cookie 即可，在覆盖的时候，由于 Cookie 具有不可 跨域名性，注意 name、path、domain 需与原 cookie 一致 删除 cookie 也一样，设置 cookie 的过期时间 expires 为过去的一个时间点，或者 maxAge = 0(Cookie 的有效期,单位为秒)即可

• 3、cookie的安全
  事实上，cookie 的使用存在争议，因为它被认为是对用户隐私的一种侵害，而且 cookie 并不安全 HTTP 协议不仅是无状态的，而且是不安全的。使用 HTTP 协议的数据不经过任何加密就直接在网络上传播， 有被截获的可能。使用 HTTP 协议传输很机密的内容是一种隐患。 如果不希望 Cookie 在 HTTP 等非安全协议中传输，可以设置 Cookie 的 secure 属性为 true。浏览 器只会在 HTTPS 和 SSL 等安全协议中传输此类 Cookie。此外，secure 属性并不能对 Cookie 内容加密，因而不能保证绝对的安全性。如果需要高安全性，需 要在程序中对 Cookie 内容加密、解密，以防泄密。也可以设置 cookie 为 HttpOnly，如果在 cookie 中设置了 HttpOnly 属性，那么通过 js 脚本将无法读 取到 cookie 信息，这样能有效的防止 XSS（跨站脚本攻击）攻击

六、Session

• 1、描述
  除了使用 Cookie，Web 应用程序中还经常使用 Session 来记录客户端状态。Session 是服务器端使用的 一种记录客户端状态的机制，使用上比 Cookie 简单一些，相应的也增加了服务器的存储压力。 Session 是另一种记录客户状态的机制，不同的是 Cookie 保存在客户端浏览器中，而 Session 保存在服务器 上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是 Session。客 户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。当程序需要为某个客户端的请求创建一个 session 时，服务器首先检查这个客户端的请求里是否已 包含了一个 session 标识（称为 SessionId）；如果已包含则说明以前已经为此客户端创建过 session，服务器就按照 SessionId 把这个 session 检索 出来，使用（检索不到，会新建一个）；如果客户端请求不包含 SessionId，则为此客户端创建一个 session 并且生成一个与此 session 相关联的 SessionId，SessionId 的值应该是一个既不会重复，又不容易被找到规律以仿造的字符 串，这个 SessionId 将被在本次响应中返回给客户端保存。保存这个 SessionId 的方式可以采用 cookie，这样在交互过程中浏览器可以自动的按照规则把这 个标识发送给服务器。但 cookie 可以被人为的禁止，则必须有其他机制以便在 cookie 被禁止时仍 然能够把 SessionId 传递回服务器。
  

• 2、与cookie的区别
  1）cookie 数据存放在客户的浏览器上，session 数据放在服务器上。
  2）cookie 相比 session 不是很安全，别人可以分析存放在本地的 cookie 并进行 cookie 欺骗,考虑到安全 应当使用 session。
  3）session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务 器性能方面，应当使用 cookie。
  4）单个 cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 cookie。而 session 存储在服务端，可以无限量存储
  5）所以：将登录信息等重要信息存放为 session;其他信息如果需要保留，可以放在 cookie 中

七、ip协议

• 1、数据报格式
  

a、版本号： 规定了数据报的 IP 协议版本（IPv4 还是 IPv6）。不同的 IP 版本使用不同的数据报格式 ， 上图是 IPv4 的数据报格式
b、首部长度： 大多数 IP 数据报不包含选项，所以一般 IP 数据报具有 20 字节的首部。
c、服务类型： 使不同类型的 IP 数据报能相互区别开来。
d、总长度： 整个 IP 数据报的长度，利用首部长度和总长度就可以是算出 IP 数据报中数据内容的起始地址。该字段长度为 16 比特，所以 IP 数据报最长可达 2^16=65535 字节，而事实上，数据报 很少有超过 1500 字节的
e、标识、标志、片偏移： 这三个字段与 IP 分片有关。此外，IPv6 不允许在路由器上对分组分片
f、生存时间： 用来确保数据报不会永远在网络中循环。设置该数据报可以经过的最多的路由器数。指定了 数据报的生存时间，经过一个路由器，它的值就减 1，当该字段为 0 时，数据报就被丢弃
g、协议： 该字段只有在一个 IP 数据报到达其目的地才有用。该字段值指示了 IP 数据报的数据部分应 交给哪个特定的传输层协议，比如，值为 6 表明要交给 TCP，而值为 17 则表明要交给 UDP
h、首部校验和： 与 UDP/TCP 的检验和不同，这个字段只检验数据报的首部，不包括数据部分。
i、选项字段： 是一个可变长字段，选项字段一直以 4 字节作为界限。这样就可以保证首部始终是 4 字节的 整数倍。很少被用到
j、**源ip和目的ip：**记录源ip和目的ip地址

• 2、数据报分并
  一个链路层帧能承载的最大数据量叫做最大传送单元（Maximun Transmission Unit,MTU）,即链路层的 MTU 限制着 IP 数据报的长度。 问题是在不同的链路上，可能使用不同的链路层协议，且每种协议可能具有不同的 MTU。 假定在某条链路上收到一个 IP 数据报，通过检查转发表确定出链路，且出链路的 MTU 比该 IP 数据报的长 度要小，如何将这个过大的 IP 数据报压缩进链路层帧的有效载荷字段呢？ 解决方案就是分片：将 IP 数据报中的数据分片为两个或更多个较小的 IP 数据报，用单独的链路层帧封装这 些较小的 IP 数据报，然后向出链路上发送这些帧，每个这些较小的数据都称为片（fragment）。
  片在到达目的地传输层前需要重新组装。
  实际上，TCP 和 UDP 都希望从网络层上收到完整的未分片的报文。IPv4 的数据报重组工作是在端系统中， 而不是在网络路由器中。 当一台目的主机从相同源收到一系列数据时，需要确定这些数据报中的某些是否是一些原来较大的数据报 中的片。而如果是片的话，需要进一步确定何时收到最后一片，并且如何将这些片拼接到一起以形成初始 的数据报。从而就用到了前边说到的 IPv4 数据报首部中的标识、标志、片偏移 字段。
  1）当生成一个数据报时，发送主机在为该数据报设置源和目的地址的同时在贴上标识号,发 送主机通常将为它发送的每个数据报标识号加1
  2）当某路由器需要对一个数据报分片时，形成的每个数据报（即片）具有初始数据报的源 地址、目的地址和标识号
  3）当目的地从同一发送主机收到一系列数据报时，它能够检查数据报的标识号以确定哪些 数据报实际上是同一较大数据报的片
  4）由于 IP 协议是不可靠服务，一个或者多个片可能永远到达不了目的地。为了让目的主机 绝对相信它已收到初始数据报的最后一个片，最后一个片的标志比特被设为 0，其余被设为 1
  5）为了让目的主机确定是否丢失了一个片，并且能按照正确的顺序重新组装片，使用偏移 字段指定该片应放在初始 IP 数据报的哪个位置> 此外，如果有一个片或者多个片未能到达，则该不完整的数据报将会被丢弃且不会交给传输 层。但如果传输层正使用着 TCP，则 TCP 将通过让源以初始数据来重传数据。因为 IP 层没有 超时重传机制，所以会重传整个数据报，而不是某个片
• 3、ipv6数据报格式
  

a、版本： 该字段用于标识 IP 版本号，IPv6 将该字段值设为 6。而如果将该字段设为 4 并不能创建一 个合法的 IPv4 数据报
b、流量类型： 类似于 IPv4 数据报中的服务类型（TOS）
c、流标签： 流标签字段是 IPv6 数据报中新增的一个字段，用来标识一条数据报的流类型，以便在网络 层区分不同的报文。
d、有效载荷长度： IPv6 数据报中在 40 定长字节数据报首部后的字节数量，即除了 IPv6 的数据报首部以外的其他部分的总长度
e、下一个首部： 当 IPv6 没有扩展报头时，该字段的作用和 IPv4 的协议字段一样。当含有扩展报头时，该字 段的值即为第一个扩展报头的类型
f、跳限制： 与 IPv4 报文中的 TTL 字段类似，转发数据报的每台路由器将对该字段的内容减 1.如果跳限 制计数到达 0，则该数据报将被丢弃
g、源地址和目的地址： 记录源 IP 地址，目的 IP 地址
h、数据

• 转载请标明出处
• 如有错误理解，还请各路大神批评指出