总结

计算机网络体系结构

OSI七层模型 TCP/IP四层模型 五层模型

image

七层模型：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

TCP/IP四层模型：网络接口层、网络层、传输层、应用层

image

各层协议

网络层：IP、ARP、RARP（后两个在OSI中认为在数据链路层，在TCP/IP协议中被认为在网络层）

传输层：TCP、UDP

应用层：HTTP、DNS、FTP、SMTP、POP3、TELNET

基于TCP的应用层协议有：HTTP、HTTPS、FTP（文件传输协议）、SMTP（发送电子邮件）、POP3（接收电子邮件)、TELNET（远程登陆协议）

基于UDP的应用层协议有：TFTP（简单文件传输协议）、SNMP（简单网络管理协议）、NTP（网络时间协议）

基于TCP和UDP的应用层协议有：DNS

简单了解

FTP

FTP协议的客户机与服务器之间需要建立两个连接， 一个用于控制数据传输（端口21）， 一个用于数据传输（端口20）。数据连接主要用于数据传输，完成文件内容的传输。控制连接主要用于传输FTP控制命令和服务器的回送消息

TFTP

在UDP之上上建立一个类似于FTP的但仅支持文件上传和下载功能的传输协议，所以它不包含FTP协议中的目录操作和用户权限等内容

SNMP

SNMP用于网络设备的管理。SNMP的工作方式：管理员需要向设备获取数据，所以SNMP提供了“读”操作；管理员需要向设备执行设置操作，所以SNMP提供了“写”操作；设备需要在重要状况改变的时候，向管理员通报事件的发生，所以SNMP提供了“Trap”操作

Get:读取网络设备的状态信息 Set：远程配置设备参数 Trap:管理站及时获取设备的重要信息

NTP

用于网络时间同步的协议，使网络中的计算机时钟同步到UTC，再配合各个时区的偏移调整就能实现精准同步对时功能

五层模型

• 物理层：解决如何在连接各种计算机的传输媒体上传输数据比特流，而不是指具体的传输媒体。

• 数据链路层（数据帧：Frame）：

  • 在物理层提供的服务基础上，数据链路层在通信的实体间建立数据链路连接

  • 不同的网络类型，发送数据的机制不同，数据链路层就是将数据包封装成能够在不同网络传输的帧

  • 采用差错控制与流量控制方法，使有差错的物理线路变成无差错的数据链路（只进行差错检验，但不纠错，如果检测到错误就丢弃该帧）

• 网络层（数据包：Packet）：把传输层传递下的数据报封装成分组（负责选择最佳路线、规划IP地址）

  • 通过路由选择算法为分组通过通信子网选择最合适的路径

    • 路由器查看数据包目标IP地址，根据路由表为数据包选择路径。路由表中的类目可以人工添加（静态路由）也可以动态生成（动态路由）

• 传输层（数据段：Segment）：建立、管理和维护端到端的连接

  • 向用户提供端到端服务，透明地传送报文

  • 提供进程间的通用数据传输服务，传输层向高层屏蔽下层数据通信的细节

• 应用层（报文：Message）：提供用户接口，特指能够发送网络流量的程序（为应用程序提供服务）

OSI中其他两层的作用：

• 表示层：处理两个通信系统间信息交换的表示方式，包括数据格式变换、数据加密与解密、数据压缩与恢复等功能

• 会话层：建立会话，通信的应用程序之间建立、维护和释放面向用户的连接（通信的应用程序之间建立会话，需要传输层建立1个或多个连接，netstat -n 查看）

数据链路层

三个基本问题

• 封装成帧

每个链路层协议都规定了帧数据部分的长度限制——最大传输单元 MTU（Maximum Transfer Unit）

帧首部和帧尾部包含许多必要的控制信息（比如帧号，不是只包含控制字符）

控制字符SOH放在第一帧的最前面（Start Of Header，首部），控制字符EOT放在最后一帧的最后面（End Of Transmission，尾部）

• 透明传输

发送端的数据链路层在数据中出现控制字符“SOH”和“EOT”的前面插入一个转移字符“ESC”

• 差错检测

循环冗余编码（CRC）

向网络层提供的服务

• 无确认的无连接服务

• 有确认的无连接服务

• 有确认的面向连接服务（需要在帧传输之前建立数据链路，也需要在帧传输结束后释放数据链路）

MAC寻址

MAC地址被烧入每个以太网网卡中（MAC地址全球唯一）

ARP协议，IP地址 ➡ MAC地址

RARP协议，MAC地址 ⬅ IP地址

为什么有MAC地址，还需要IP地址？

• 虽然设备的MAC地址唯一，但是设备不是固定在一个地方的，它很有可能是要移动的，所以无法知道它具体的位置。

• 并且如果直接用MAC地址进行寻址，如果网络规模比较大的话，交换机需要保存所有的MAC地址，很不现实

MAC地址类似于身份证号，IP地址（有定位功能）类似于你家在哪，或者你当前住在哪里。当需要找你的时候，首先通过IP寻址，缩小范围，然后通过MAC地址准确定位到你

网络层

IP协议作用

• 寻址和路由选择

• 分段与重组（不同类型网络所规定的最大传输单元MTU不同）

• IP地址和MAC地址的转换，将不同格式的物理地址（即，MAC地址）转换为统一的IP地址

传输层

TCP和UDP的区别、特点

TCP的主要特点

• 面向连接（也就是说，利用TCP通信的两台主机首先要经历一个建立连接的过程，等到连接建立后才开始传输数据）

• 具有可靠性（校验和、重传控制、序号标识、滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制）

• 全双工通信通信方式

• 流量控制（“滑动窗口”的方式）

• 拥塞控制

• 每一条TCP连接只能是点对点的（一对一）

• 面向字节流

UDP的主要特点

• 无连接（所谓全双工，半双工，单工是指面向连接时才有的说法，所以UDP没有此说法）

• 无拥塞控制（会以尽可能快的速度传输）

• 支持一对一、一对多、多对一和多对多的交互通信

• 面向报文

• 首部开销小，8个字节（只有四个字段：源端口、目的端口、长度、检验和）（TCP首部20个字节）

采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大

UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响，使用场景：语音通话、直播

区别总结

• TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

• TCP提供可靠的服务。通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

• UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。

• 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

• TCP对系统资源要求较多，UDP对系统资源要求较少。

类型	特点	性能	应用场景	首部字节
TCP	面向连接、可靠、字节流	传输效率慢，所需资源多	文件、邮件传输	20-60
UDP	无连接、不可靠、数据报文段	传输速度快，所需资源少	语音、视频、直播	8

TCP协议采用哪些机制保证数据的可靠传输

• 数据分割，对数据段进行编号

• 校验和

• 接时的三次握手和断开时的四次挥手

• 超时重传

• 拥塞控制

• 流量控制

如何实现流量控制

流量控制：点对点通信量的控制。TCP支持根据接收端的处理能力，来决定发送端的发送速度

在TCP报文段首部中有一个16位窗口长度，当接收端接收到发送方的数据后，在应答报文ACK中就将自身缓冲区的剩余大小，放入16窗口大小中。这个大小随数据传输情况而变，窗口越大，网络吞吐量越高，而一旦接收方发现自身的缓冲区快满了，就将窗口设置为更小的值通知发送方。如果缓冲区满，就将窗口置为0，发送方收到后就不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

注：16位的窗口大小最大能表示65535个字节（64K），但是TCP的窗口大小最大并不是64K。在TCP首部中40个字节的选项中还包含了一个窗口扩大因子M，实际的窗口大小就是16为窗口字段的值左移M位。每移一位，扩大两倍

如何实现拥塞控制

拥塞：如果网络非常拥堵，此时再发送数据就会加重网络负担，那么发送的数据段很可能超过了最大生存时间也没有到达接收方，就会产生大量丢包问题，从而进行大量的超时重传，严重影响传输

拥塞控制：TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性

拥塞控制目的：为了防止过多的数据注入到网络中，避免网络中的路由器、链路过载

拥塞控制过程：TCP发送将维护一个拥塞窗口的状态变量，该变量随着网络拥塞程度动态变化，通过满开始、拥塞避免等算法减小网络拥塞的发生

• 慢开始（指数增长）

• 拥塞避免（线性增长）

• 快重传

• 快恢复

TCP的几个状态

• SYN表示建立连接，

• FIN表示关闭连接，

• ACK表示响应，

• PSH表示有数据传输，

• RST表示连接重置

三次握手

过程

• 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client 进入syn_sent状态，等待Server确认

• 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1,随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入syn_rcvd状态

• 第三次握手：Client收到确认后，检查ack=J+1,ACK是否为1，如果正确则将标志位ACK为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入established状态，完成三次握手，随后Client和Server之间可以开始传输数据了

为什么是三次

• 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤

• 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

两次握手只能保证单向连接是畅通的

只有经过第三次握手，才能确保双向都可以接收到对方的发送的数据

• 第一次握手：服务端知道自己接受、对方发送没问题

• 第二次握手：客户端知道自己接受、发送、对方接受和发送没问题

• 第三次握手：服务端知道自己发送没问题，对方接受没问题

四次挥手

过程

• Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入fin_wait_1状态

• Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入Close_wait状态。此时TCP连接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收

• Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入Last_ack状态

• Client收到FIN后，Client进入Time_wait状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入Closed状态，完成四次挥手

为什么是四次

保证服务端数据发送完

由于TCP连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭

TIME-WAIT的作用

MSL 是 MaximumSegmentLifetime 英文的缩写，中文可以译为“报文最大生存时间”

• 为了保证客户端发送的最后一个ack报文段能够到达服务器

  • 因为这最后一个ack确认包可能会丢失，然后服务器就会超时重传第三次挥手的fin信息报，然后客户端再重传一次第四次挥手的ack报文

• 在第四次挥手后，经过2msl的时间足以让本次连接产生的所有报文段都从网络中消失，这样下一次新的连接中就肯定不会出现旧连接的报文段了

应用层

浏览器输入URL后，按下回车会发生什么

• 浏览器查找域名的IP地址（DNS协议）

  • 浏览器会从主机的Hosts文件中查看是否有该域名和IP地址的映射；

  • 如果Hosts文件没有，浏览器会查看自己的缓存；

  • 当上面两个方法都行不通时，只能去请求DNS服务器来获取IP地址；

• 浏览器与目标服务器建立TCP连接

  • 获取到IP地址后，建立TCP连接、三次握手；（TCP协议）

  • 确认连接后发送一个HTTP请求报文；（HTTP协议）

  • 服务器处理请求，并对请求做出响应；

  • 浏览器收到服务器响应，得到html代码；

• html页面的解析与渲染

HTTP和HTTPS的区别

• https协议需要到CA（Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用

• http是超文本传输协议，信息是明文传输，https则是具有安全性的 SSL/TLS（TLS是基于SSL的）加密传输协议（https的加密机制是一种共享密钥加密和公开加密并用的混合加密机制）

• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443

• http的连接很简单，是无状态的。Https协议是由SSL/TLS+Http协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

HTTP	HTTPS
默认端口80	默认端口443
明文传输、数据未加密、安全性差	传输过程ssl加密、安全性较好
响应速度快、消耗资源少	响应速度慢、资源消耗多、需要用的CA证书

HTTP明文传输带来的风险：

• 窃听风险：第三方可以获取通信内容

• 篡改风险：第三方可以修改通信内容

• 冒充风险：第三方可以冒充他人身份参与通信

HTTPS加密过程

• 客户端给服务器发送一个请求，包括协议版本号、随机数，以及客户端支持的加密算法

• 服务器确认双方使用的加密方法，并给出一个服务器产生的随机数和CA证书给客户端，内容包括：证书的发布机构、有效期、所有者、签名以及公钥等

• 客户端对发来的公钥进行真伪校验，如果有效，生成一个新的随机数，并使用CA证书中的公钥，加密这个随机数，发送给服务器

• 服务器使用自己的私钥，获取客户端发送的随机数

• 客户端和服务器根据约定的加密方法，使用前面的三个随机数，生成“对话密钥”，用来加密接下来的整个对话过程

细节过程：

image

整体过程：

[图片上传失败...(image-61368b-1601180318144)]

为什么客户端和服务端都需要发送一个Finish报文

Finish报文是对至今全部报文的整体校验值（也就是HASH值）。当客户端把这个值通过得到的公钥进行加密的时候，服务器得到之后对其进行解密，然后再对全部报文进行一个HASH求值。如果这个值跟解密得到的值相等的话，那么说明客户端时可信赖的

同样的，服务器发送这也的一个整体校验值，用来客户端验证服务器是否是真正要进行通信的那一个

综上：Finish报文用来校验双方的身份

为什么使用三个随机数

• 向前安全性。加入随机参数，使得：即使现在所有密钥都泄露了，历史消息也不会被破解

• 增加随机性

  • 不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。

  • SSL 的协议默认不信任每个主机都能产生完全随机的数，如果只使用一个伪随机的数来生成秘钥，就很容易被破解。

  • 通过使用三个随机数的方式，增加了自由度，一个伪随机可能被破解，但是三个伪随机就很接近于随机了，因此可以使用这种方法来保持生成秘钥的随机性和安全性

数据传输需要用对称加密的原因

非对称加密的加解密效率是非常低的

对称加密算法

• DES

• AES

非对称加密算法

• RSA

• DSA

HTTP请求有哪些

方法	描述
GET	向特定资源发送请求，查询数据，并返回实体
POST	向指定资源提交数据进行处理请求，可能会导致新的资源建立、已有资源修改
PUT	向服务器上传新的内容
HEAD	类似GET请求，返回的响应中没有具体的内容，用于获取报头
DELETE	请求服务器删除指定标识的资源

GET和POST的区别

• GET请求时幂等的（幂等的意味着对同一个URL的多个请求应用返回同样的结果）

• GET在浏览器回退时是无害的，而POST会再次提交请求

• GET请求会被浏览器主动cache，而POST不会，除非手动设置

• GET请求只能进行url编码，而POST支持多种编码方式

	GET	POST
可见性	数据在URL中对所有人可见	数据不会显示在URL中
安全性	与POST相比，GET的安全性较差，因为所有发送的数据是URL的一部分	安全，因为参数不会保存在浏览器历史或服务器日志中
数据长度	受限制，浏览器对URL长度有限制	无限制
缓存	能被缓存	不能被缓存

PUT和POST的区别

幂等性：一个幂等操作的特点就是其任意多次执行所产生的影响均与依次一次执行的影响相同（一次和多次请求某一个资源应该具有同样的副作用）

POST方法不是幂等的

PUT方法具有幂等性

• PUT请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以PUT用来改资源）

• Post请求：后一个请求不会把第一个请求覆盖掉。（所以Post用来增资源）

HTTP状态码

服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果

状态码	类别	原因短语
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

• 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应

• 200 OK 请求成功，响应消息返回所请求的对象

• 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用

• 206 Partial Content ：表示客户端进行了范围请求。响应报文包含由 Content-Range 指定范围的实体内容

• 301 Moved Permanently 永久性重定向，请求对象已永久迁移

• 302 表示临时重定向。请求对象暂时迁移

• 400 Bad Request ：请求报文中存在语法错误

• 403 Forbidden 拒绝访问。服务器理解请求客户端的请求，但是拒绝执行此请求（一般是没有权限访问此网站）

• 404 Not Found 服务器上不存在所请求的对象

• 500 Internal Server Error ：服务器内部错误，无法完成请求

• 502 Bad Gateway 错误的网关

重定向和转发的区别

• 请求次数，定向是浏览器向服务器发送一个请求并收到响应后再次向一个新地址发出请求，转发是服务器收到请求后为了完成响应跳转到一个新的地址；重定向至少请求两次，转发请求一次；

• 地址栏，重定向地址栏会发生变化，转发地址栏不会发生变化

• 跳转限制，重定向可以跳转到任意URL，转发只能跳转本站点资源

• 发生行为不同，重定向是客户端行为，转发是服务器端行为

• 是否共享数据，重定向两次请求不共享数据，转发一次请求共享数据

无效链接

• 死链接（Dead Links）指的是无效链接，也就是那些不可到达的链接。通俗地理解是以前可以通过点击这个链接到达网站页面，后续可能由于网站迁移、改版或操作不当等原因，使得链接指向的目标页面不存在而无法访问所遗留的链接，即称为死链接。

• 访问死链接时，一般会出现“抱歉，您所访问的页面不存在”的提示信息或者 404 状态页面。

HTTP常见首部行

请求报文

• Host：请求的目标域名和端口号

• User-agent：向服务器发送浏览器的版本、系统、应用程序信息

• Cookie：当前域名下的cookie数据

• Accept-language：向服务器声明客户机接收的语言版本

• Connection：告诉服务器采用什么连接方式

响应报文

• Date：服务器发送资源时的服务器时间

• Server：HTTP服务器的应用程序信息

• Location：重定向，让客户端跳转到新的URL进行访问

• Last-Modified：服务器发来的当前资源的最后一次修改时间，如果下一次请求时，服务器上当前资源的修改时间比这个大（更晚），就返回新的资源内容

• Content-Length：消息实体的传输长度

• Content-Type：响应体的媒体资源类型（比如html类型，UTF-8编码等等

HTTP不同版本的区别

HTTP 1.0

• 默认短连接（每次发请求都要新建一个 TCP连接，然后进行三次握手，Connection: close）

HTTP 1.1

• 默认长连接（一次TCP连接可以多次请求，Connection: keep-alive）

• 增加connection header，（该header用来说明客户端与服务器端TCP的连接方式）

• 新增了五种请求方法：PUT、DELETE、CONNECT、TRACE、OPTIONS

• 增加更多的缓存策略（如：Entity tag，If-Match）

• 支持断点续传

• 错误状态码增多（新增24个）

• 新增HOST请求头（用来实现虚拟主机技术）

  • 一个IP地址可以对应多个域名。所以通过HOST（指定请求服务器的域名/IP地址和端口号）可以确定具体访问站点

HTTP 2.0

• 解析基于二进制，解析错误少，更高效（HTTP/1.X解析基于文本）

  • 帧对数据进行顺序标识；因为有了序列，服务器可以并行的传输数据

• 多路复用，降低开销（一次TCP连接可以处理多个请求）

  • 每一组请求和响应，都会绑定到一个数据流，这个数据流会有个唯一的ID来标识。然后数据流内的请求和响应就会被切分成多个帧，在对每个帧进行二进制编码，同时这个帧会携带数据流的ID，那么客户端或者服务端就可以通过这个ID来判断新到达的帧是属于哪个数据流的

• 首部压缩

  • 通过HPACK算法来对首部进行压缩。大概原理是在客户端和服务端维护静态字典和动态字典。字典中的key为整数，value 为常见的首部的键值对，或者是头部的名称

• 服务端推送

  • 服务器可以对客户端的一个请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端明确地请求

HTTP协议是无状态的 和 Connection: keep-alive的区别

无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。从另一方面讲，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。（上一次的请求对这次的请求没有任何影响，服务端也不会对客户端上一次的请求进行任何记录处理）

HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）

从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接

Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。

网页的缓存技术

• Cookie

• Session

• localStorage

• sessionStorage

Session 和 Cookie的区别

前提：由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户

比如你用浏览器访问淘宝网登录了，按道理说，你就可以查看自己账号购物车里的宝贝列表了，但假设不用cookie与session等技术保存用户的信息，http是不知道你对淘宝网的多次请求是同一个人的

相同点

cookie和session都是用来跟踪浏览器用户身份的会话方式

不同点

• cookie数据存放在客户的浏览器上，session数据放在服务器上

• session 默认被存在在服务器的一个文件里（不是内存）

• session 可以放在 文件、数据库、或内存中都可以

• 重点：session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）

• cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session

• session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用COOKIE

• 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie

cookie也可以保存用户的用户名和密码

当我们登录网站勾选保存用户名和密码的时候，一般保存的都是cookie，将用户名和密码的cookie保存到硬盘中，这样再次登录的时候浏览器直接将cookie发送到服务端验证，直接username和password保存到客户端

注意

• “session存放在哪里：服务器端的内存中。”指的是Tomcat保存session的方式。对于PHP而言是保存在文件中

• session删除情况：超时、程序调用HttpSession.invalidate()、程序关闭；

• session不会因为浏览器的关闭而删除。但是存有session ID的cookie的默认过期时间是会话级别。也就是用户关闭了浏览器，那么存储在客户端的session ID便会丢失

禁用cookie

如果客户端禁用了cookie，通常有两种方法实现session而不依赖cookie：

• URL重写，就是把sessionId直接附加在URL路径的后面

• 表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器

Session id分布式负载均衡问题

• session ticket

session id缺点：往往只保留在一台服务器上，所以，如果客户端的请求发到另一台服务器，就无法恢复对话

为了解决上述问题，出现了Session ticket

客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法（此外还包括比如：有效期、压缩算法等）。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了

• redis/memcached

cookie存一个key，具体信息存在数据库里，可以用memcached/redis这些基于内存的key-value存储来加速

• IP哈希

每个请求按访问IP的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题

ARP协议过程

• 首先，每个主机都会有自己的ARP缓存区中建立一个ARP列表，以表示IP地址和MAC地址之间的对应关系

• 当源主机要发送数据时，首先检测ARP列表中是否对应IP地址的目的主机的MAC地址如果有，则直接发送数据。如果没有，就向本网段的所有主机发送ARP数据包，内容:我是IP地址，mac地址，谁是IP地址，mac?

• 当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包。如果是，则首先从数据包中取出源主机的IP和mac地址写入到ARP列表中，如果以存在，则覆盖。然后将自己的mac地址写入arp响应包中，告诉源主机自己是它想要找的mac地址

• 源主机收到ARP响应包后，将目的主机的IP和mac地址写入arp列表，并利用此信息发送数据

• 如果源主机一直没有收到arp响应数据包，表示arp查询失败

DNS协议过程

image

• 操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析

• 如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析

• 如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性

• 如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性

• 如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机

• 如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机

递归查询

image

迭代查询

image

DNS

DNS域名解析时用UDP

DNS区域传送时用TCP

DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。 这种情况下，使用TCP协议

Ping时，用到了哪些协议

• DNS协议，通过DNS协议，将ping后接的域名转换为ip地址。（DNS使用的传输层协议是UDP）

• ARP协议，通过ARP解析服务，由ip地址解析出MAC地址，以在数据链路层传输。

• ICMP协议，ping是为了测试另一台主机是否可达，发送一份ICMP回显请求给目标主机，并等待ICMP回显应答。（ICMP用于在ip主机、路由器间传递网络是否通畅、主机是否可达等控制信息）

扩展

网络类型

按照不同的划分依据

地理位置

局域网、城域网、广域网、个人网

传输介质

有线网、光纤网、无线网

拓扑结构

星型结构、环形结构、总线型结构

透明传输

透明传输：传输的内容从源到目的过程中，底层协议不对业务数据内容做任何改变。从上层角度看，似乎就是一个透明的管道，什么都可以传（无论是什么报文都可以传输）

非透明传输：底层协议要对传输内容有限制或者修改（某些特殊字符不能传输）

URL

URL(Uniform Resource Locator) 地址用于描述一个网络上的资源，基本格式如下：

schema://host[:port]/path/.../[?query-string][#anchor]

• scheme： 指定低层使用的协议，eg：http，https，ftp，…

• host： HTTP服务器的IP地址或者域名

• port#： HTTP服务器的默认端口是80，这种情况下端口号可以省略；如果使用了别的端口，必须指明，例如： http://www.cnblogs.com:8080/

• path：访问资源的路径

• query-string：发送给http服务器的数据

• anchor： 锚