java面试（四） 计算机网络

目录

 

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

三次握手(为什么不是两次、为什么不是四次)

四次挥手（为什么是四次挥手不是三次）

保活计时器

确认应答机制（ACK）

滑动窗口

超时重传机制（去重机制、快重传）

流量控制

拥塞控制（慢启动、拥塞窗口）

TCP可靠性保证的机制

TCP与UDP的区别

Post与get区别

http与https

http常见返回码

http请求的过程

怎么防止http请求的攻击

对称加密与非对称加密

Cookie和session 的区别

---

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

OSI分层 （7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

TCP/IP分层（4层）：网络接口层、 网际层、运输层、 应用层。

五层协议 （5层）：物理层、数据链路层、网络层、运输层、 应用层。

每一层的协议如下：

物理层：RJ45、CLOCK、IEEE802.3 （中继器，集线器）

数据链路：PPP、FR、HDLC、VLAN、MAC （网桥，交换机）

网络层：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 （路由器）

传输层：TCP、UDP、SPX

会话层：NFS、SQL、NETBIOS、RPC

表示层：JPEG、MPEG、ASII

应用层：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

每一层的作用如下：

物理层：通过媒介传输比特,确定机械及电气规范（比特Bit）

数据链路层：将比特组装成帧和点到点的传递（帧Frame）

网络层：负责数据包从源到宿的传递和网际互连（包PackeT）

传输层：提供端到端的可靠报文传递和错误恢复（段Segment）

会话层：建立、管理和终止会话（会话协议数据单元SPDU）

表示层：对数据进行翻译、加密和压缩（表示协议数据单元PPDU）

应用层：允许访问OSI环境的手段（应用协议数据单元APDU）

三次握手(为什么不是两次、为什么不是四次)

所谓三次握手(Three-way Handshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息.在socket编程中，客户端执行connect()时。将触发三次握手。

（1）首先客户端向服务器端发送一段TCP报文，其中：

• 标记位为SYN，表示“请求建立新连接”;序号为Seq=X（X一般为1）；
• 随后客户端进入SYN-SENT阶段。

（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：

• 标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
• 序号为Seq=y；
• 确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。

（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：

• 标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；
• 序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；
• 确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
• 随后客户端进入ESTABLISHED阶段。

服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

 

三次握手建立连接时，发送方再次发送确认的必要性？

主 要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次 新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多 资源就这样白白浪费了。

四次挥手（为什么是四次挥手不是三次）

TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。

（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：

• 标记位为FIN，表示“请求释放连接“；
• 序号为Seq=U；
• 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。

注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。

（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

• 标记位为ACK，表示“接收到客户端发送的释放连接的请求”；序号为Seq=V；
• 确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；
• 随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段

前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

• 标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
• 序号为Seq=W；
• 确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。

随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

• 标记位为ACK，表示“接收到服务器准备好释放连接的信号”。
• 序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。
• 确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。

随后客户端开始在TIME-WAIT阶段等待2MSL

为什么等待2MSL？ 

当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。

为什么四次挥手

1. 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
2. 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

 

保活计时器

• 目的：主要是为了防止两个TCP连接出现长时间的空闲。当客户端与服务器端建立TCP连接后，很长时间内客户端都没有向服务器端发送数据，此时很有可能是客户端出现故障，而服务器端会一直处于等待状态。保活计时器就是解决这种问题而生的。
• 工作原理：每当服务器端收到客户端的数据时，都将保活计时器重新设置（通常设置为2小时）。过了2小时后，服务器端如果没有收到客户端的数据，会发送探测报文段给客户端，并且每隔75秒发送一个，当连续发送10次以后，仍没有收到对端的来信，则服务器端认为客户端出现故障，并会终止连接。

TCP中的四个计时器包括重传计时器、坚持计时器、保活计时器、时间等待计时器

确认应答机制（ACK）

TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时确认首部的确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。
 

滑动窗口

发送窗口：在任意时刻，发送发都维持一组连续的允许发送的帧的序号，称为发送窗口。
接收窗口：发送窗口用来对发送方进行流量控制，而发送窗口的大小 W 代表在还没有收到对方确认信息的情况下发送方最多还可以发送多少个数据帧。

在接收端设置接收窗口是为了控制可以接受哪些数据帧而不可以接收哪些帧。在接收方只有当收到的数据帧的序号落入接收窗口内才允许将该数据帧手下。若接收到的数据帧落在了接收窗口之外，则一律将其丢弃。

在发送端，每收到一个确认帧，发送窗口就向前滑动一个帧的位置，当发送窗口内没有可以发送的帧（即窗口内全部是已发送，但未接收到确认的帧），发送方就会停止发送，直到收到接收方发送的确认帧使窗口移动，窗口内有可以发送的帧，之后才开始继续发送。

滑动窗口的分类

停止等待、后退N帧、选择重传。他们之间主要的区别就是：发送窗口和接收窗口大小的区别。

• 停止等待协议：发送窗口大小 = 1， 接收窗口大小= 1
• 后退N帧协议：发送窗口大小 > 1，接收窗口大小 = 1
• 选择重传协议：发送窗口大小 > 1， 接收窗口大小 > 1

停止等待协议

规则：源站发送单个帧后就必须等待确认，在目的站的回答到达源站之前，源站不能发送其他的数据帧

在停止等待协议中，除了数据丢失的问题，还有可能存在以下两种差错：

1.到达目的站的数据帧可能遭到破坏。

解决办法：源站在发送一个帧后，就为这个帧装一个计时器，在一个帧发送之后，源站等待确认，如果在计时器时间到达时未收到确认，则再次发送相同的帧。

2.数据帧正确，但是却认真没有收到

此时接收方已经收到了正确的数据帧，但是发送方收不到却认真，因此发送方会重传已经被接收的数据帧，接收方收到同样的数据帧就会丢弃该帧，并重传一个该帧对应的却认真。

【总结】

• 【1】接收方收到相同的数据：发送方超时重传
• 【2】发送方收到相同的确认帧：发送方发送了重复的数据
• 【3】接收窗口大小 = 1， 发送窗口大小 = 1

 

后退N帧

发送方不需要在收到上一帧的ACK后才能开始发送下下一帧，而是可以连续发送帧。当接收方检测出失序的信息帧之后，要求发送方重发最后一个正确信息帧之后的所有未被确认的帧；或者当发送方发送了N个帧之后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判定为出错或者丢失，此时发送方就不得不重传该出错帧及之后的N个帧。

注意：接收方只允许按照顺序接受帧。

为了减少开销，后退N帧协议还规定接收端不一定每收到一个正确的数据帧就必须立即发回一个却认真，而是可以在连续收到好几个正确的数据帧后，才对最后一个数据帧发送确认信息，或者可以在当自己有数据要发送的时候才将对以前正确收到的帧加以捎带确认。

选择重传

只重传出现差错的数据帧或者是计时器超时的数据帧。每一个发送缓冲区对应一个计时器，当计时器超时的时候，缓冲区的帧就会重传。另外，该协议使用了比上述其他协议更有效的差错处理策略，即一旦接收方怀疑帧出错，就会发送一个否定帧NAK给发送方，要求发送方对NAK中制定的帧进行重传。

https://blog.csdn.net/xiaojie_570/article/details/87904328

 

超时重传机制（去重机制、快重传）

当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个闹钟，到点了还没有收到应答则进行重传）

未收到确认不一定就是发送的数据包丢了，还可能是确认的ACK丢了：

 

当接收方接收到重复的数据时就将其丢掉，重新发送ACK。而要识别出重复的数据，就要用到序列号了，利用序列号很容易就可以做到去重的效果。
重传时间的确定：报文段发出到收到应答中间有一个报文段的往返时间RTT，显然超时重传时间RTO会略大于这个RTT，TCP会根据网络情况动态的计算RTT，即RTO是不断变化的。在Linux中，超时以500ms为单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。其规律为：如果重发一次仍得不到应答，就等待2*500ms后再进行重传，如果仍然得不到应答就等待4*500ms后重传，依次类推，以指数形式递增，重传次数累计到一定次数后，TCP认为网络或对端主机出现异常，就会强行关闭连接。
 

流量控制

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。 

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

注意：窗口大小不受16位窗口大小限制，在TCP首部40字节选项中还包含一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。 

拥塞控制（慢启动、拥塞窗口）

TCP的四种拥塞控制算法
1.慢开始
2.拥塞控制
3.快重传
4.快恢复

 

 

 

 

TCP可靠性保证的机制

1. 检验和
2. 序列号
3. 确认应答机制（ACK）
4. 超时重传机制
5. 连接管理机制：即TCP建立连接时的三次握手和断开连接时的四次挥手。
6. 流量控制
7. 拥塞控制

https://blog.csdn.net/xuzhangze/article/details/80490362

 

TCP与UDP的区别

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

• TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务。
• 虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为
• 对数据准确性要求高，速度可以相对较慢的，可以选用TCP

 

Post与get区别

它们的本质都是 TCP 链接，并无区别。但是由于 HTTP 的规定以及浏览器/服务器的限制，导致它们在应用过程中可能会有所不同。

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

GET产生的URL地址可以被Bookmark，而POST不可以。

GET请求会被浏览器主动cache（缓存），而POST不会，除非手动设置。

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

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

GET请求在URL中传送的参数是有长度限制的，而POST么有。

对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

GET参数通过URL传递，POST放在Request body中。

GET和POST都是TCP链接。GET产生一个TCP数据包；而POST会产生两个TCP数据包。
 

http与https

Http：超文本传输协议（Http，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。设计Http最初的目的是为了提供一种发布和接收HTML页面的方法。它可以使浏览器更加高效。Http协议是以明文方式发送信息的，如果黑客截取了Web浏览器和服务器之间的传输报文，就可以直接获得其中的信息。

Http原理：

① 客户端的浏览器首先要通过网络与服务器建立连接，该连接是通过TCP 来完成的，一般 TCP 连接的端口号是80。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和许可内容。

② 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。
 

HTTPS是以安全为目标的Http通道，是Http的安全版。Https的安全基础是SSL。SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。

Https原理：

① 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器；

② 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数；

③ 客户端对服务器的证书进行验证（有关验证证书，可以参考数字签名），并抽取服务器的公用密钥；然后，再产生一个称作 pre_master_secret 的随机密码串，并使用服务器的公用密钥对其进行加密（参考非对称加 / 解密），并将加密后的信息发送给服务器；

④ 客户端与服务器端根据 pre_master_secret 以及客户端与服务器的随机数值独立计算出加密和 MAC密钥（参考 DH密钥交换算法） ；

⑤ 客户端将所有握手消息的 MAC 值发送给服务器；

⑥ 服务器将所有握手消息的 MAC 值发送给客户端。

 

• https协议需要到CA  （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(原来网易官网是http，而网易邮箱是https。)
• http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• http的连接很简单，是无状态的。Https协议是由SSL+Http协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

https://blog.csdn.net/qq_38289815/article/details/80969419

http常见返回码

 

• 1XX信息性状态码（Informational）服务器正在处理请求
• 2XX成功状态码（Success）请求已正常处理完毕
• 3XX重定向状态码（Redirection）需要进行额外操作以完成请求
• 4XX客户端错误状态码（Client Error）客户端原因导致服务器无法处理请求
• 5XX服务器错误状态码（Server Error）服务器原因导致处理请求出错

2XX成功

• 200 OK 表示请求被服务器正常处理
• 204 No Content 表示请求已成功处理，但是没有内容返回（就应该没有内容返回的状态）
• 206 Partial Content 表示服务器已经完成了部分GET请求

3XX 重定向

• 301 Moved Permanently 永久重定向，表示请求的资源已经永久的搬到了其他位置
• 302 Found 临时重定向 表示请求的资源临时搬到了其他位置
• 303 See Other 表示请求资源存在另一个URI,应该使用GET定向获取请求资源
• 304 Not Modified 表示客户端发送附带条件的请求（GET方法请求报文的），条件不满足

4XX客户端错误

• 400 Bad Request 表示请求报文存在语法错误或参数错误，服务器不理解
• 401 Unauthorized 表示发送的请求需要有HTTP认证或者认证失败了
• 403 Forbidden 表示请求资源的访问被服务器拒绝了
• 404 Not Found 表示服务器找不到你请求的资源了

5XX服务器错误

• 500 internal Server Error 表示服务器执行请求的时候出错了
• 503 Service Unavailable 表示服务器超负荷或正停机维护，无法

 

http请求的过程

1. 对www.baidu.com这个网址进行DNS域名解析，得到对应的IP地址
2. 根据这个IP，找到对应的服务器，发起TCP的三次握手
3. 建立TCP连接后发起HTTP请求
4. 服务器响应HTTP请求，浏览器得到html代码
5. 浏览器解析html代码，并请求html代码中的资源（如js、css图片等）（先得到html代码，才能去找这些资源）
6. 浏览器对页面进行渲染呈现给用户

注：

1.DNS域名解析采用的是递归查询的方式，过程是，先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的web浏览器

2.为什么HTTP协议要基于TCP来实现？  TCP是一个端到端的可靠的面相连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）

3.最后一步浏览器是如何对页面进行渲染的？  

• a）解析html文件构成 DOM树，
• b）解析CSS文件构成渲染树，
• c）边解析，边渲染 ，  
• d）JS 单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

怎么防止http请求的攻击

在前端服务器通过同一网络连接将多个请求转发到后端服务器的情况下会出现HTTP请求走私漏洞，并且用于后端连接的协议存在两个服务器不同意关于两者之间边界的风险要求。防止HTTP请求走私漏洞的一些通用方法如下：

• 禁用后端连接的重用，以便通过单独的网络连接发送每个后端请求。
• 使用HTTP / 2进行后端连接，因为此协议可防止请求之间的边界模糊不清。
• 为前端和后端服务器使用完全相同的Web服务器软件，以便他们就请求之间的界限达成一致。
• 在某些情况下，可以通过使前端服务器规范化模糊请求或使后端服务器拒绝模糊请求并关闭网络连接来避免漏洞。然而，这些方法可能比上面确定的通用缓解更容易出错。

对称加密与非对称加密

对称加密

client 用来加密的 password 和 server 用来解密的 password 相同，所以叫对称加密。

 

• 优点：加密简单，效率高。
• 缺点：不够安全，如果 client 的 password 被盗窃，就没有安全性了，例如 APP 中使用对称加密，APP 是可以被反编译的，就能拿到 password 了。

所以，对称加密适合在后端服务接口调用时使用，不适合在对外暴露的客户端中使用。常用的加密方式有 DES、AES。

非对称加密

client 用来加密的 password 和 server 用来解密的 password 不同，所以叫非对称加密。分为一对密钥（公钥 public key、私钥 private key 的组合），使用公钥加密，必须使用私钥解密。

使用步骤：

1. 开发人员生成一对密钥，server保存私钥，公钥给client。
2. Client 保存公钥，使用公钥加密。
3. Server 保存私钥，使用私钥解密。

• 优点：安全性极高。
• 缺点：加密复杂度高，效率低。

所以，非对称加密适合使用在 APP 中，还有对安全性要求极高的支付、金融场景。常用的加密方式主要是 RSA。

 

Cookie和session 的区别

cookie是Web服务器发送给浏览器的信息。浏览器会在本地文件中给每一个Web服务器存储cookie。以后浏览器在给特定的Web服务器发请求的时候，同时会发送所有为该服务器存储的cookie。

下面列出了session和cookie的区别：

无论客户端浏览器做怎么样的设置，session都应该能正常工作。客户端可以选择禁用cookie，但是，session仍然是能够工作的，因为客户端无法禁用服务端的session。

在存储的数据量方面session和cookies也是不一样的。session能够存储任意的Java对象，cookie只能存储String类型的对象。