计算机网络面试总结（附答案）

1、OSI：

开放系统互联参考模型：力求将网络简化，并以模块化的方式来设计网络。OSI并不是一个标准，而是在制定标准时所使用的概念性框架。
先从应用层到物理层，再从物理层到应用层处理数据头部。
OST将计算机网络共分为7层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
（1）物理层：机械、电子、定时借口通信道路上的原始比特流传输。激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性。该层为上层协议提供了一个传输数据的物理媒体。（比特bit）数据的单位，下同。
（2）数据链路层：负责准备物理传输、CRC校验、错误通知、网络拓扑、流控等。我们所熟知的MAC地址和交换机都工作在这一层。上次传下来的包在这一层被分割封装后叫做帧（Frame）；数据链路层在不可靠的物理介质上提供可靠的传输。将原始比特流转变成逻辑传输线路。该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。（帧frame）
（3）网络层：负责管理网络地址，定位设备，决定路由。IP地址和路由器就是工作在这一层。上层的数据段在这一层被分割封装后叫做包（Packet），包有两种，一种叫做用户数据包（Data packets），是上层传下来的用户数据；另一种叫路由更新包（Route update packets），是直接由路由器发出来的，用来和其他路由器进行路由信息交换。网络层负责控制子网的运行，包括对子网间的数据包进行路由选择、逻辑编址、分组传输。此外、网络层还可以实现拥塞控制、网际互联等功能。（包packet）
（4）传输层：负责分割、组合数据，实现端到端的逻辑连接。数据在会话层、表示层、应用层都是整体的，到了这一层开始被分割，这一次被分割后的数据被称为段（Segment）。三次握手，面向连接或非面向连接的服务，流控等都发生在这一层。第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。（段segment）
传输层协议的代表包括：TCP、UDP、SPX等。
（5）会话层：负责建立、维护、控制会话，区分不同的会话，以及提供单工（Simplex）、半双工（Half duplex）、全双工（Full duplex）三种通信模式的服务。我们平时所知的NFS、RPC、X Windows等都工作在这一层。会话层管理主机之间的会话进程，即负责建立、管理、终止进程间的会话、还利用在数据中插入校验点来实现数据的同步。（会话协议数据单元SPDU）
（6）表示层：负责数据的编码、转化、确保应用层的正常工作。这一层、是将我们看到的界面与二进制间互相转化的地方，就是我们的语言与机器语言间的转化。这一层根据不同的应用目的将数据处理为不同的格式，表现出来就是我们看到的各种各样的文件扩展名。表示对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。（表示协议数据单元PPDU）
（7）应用层：就是应用程序。这一层负责确定通信对象，并确保由足够的资源用于通信。为操作系统或网络应用程序提供访问网络服务的接口。（应用协议数据单元APDU）
应用层协议的代表包括：Telnet、FTP、HTTP、SNMP等。
OSI的实现：TCP/IP.

2、TCP的三次握手：

传输控制协议TCP简介：
1、面向连接的、可靠的、基于字节流的传输层通讯协议；
2、将应用层的数据流分割成报文段并发送给目标节点的TCP层；
3、数据包都有序号、对方收到则发送ACK确认，未收到则重传；
4、使用校验和来检验数据在传输过程中是否有误。
TCP报文段的首部格式：

源端口（Source Port），目标端口（Destination Port）：各2字节，用于寻找发端和收端应用进程。源端口号，标识主机上发起传送的应用程序；目的端口号标识主机上传送要到达的应用程序。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。
序号：占4字节，32位。标示字节流中的每一个字节。
确认号：占4字节，是期望收到对方下一个报文段的第一个数据字节的序号。Ack=N，则N-1
为止的所有数据都已经达到。
数据偏移：占4位，指出TCP报文段的数据开始的地方距离TCP报文段的起始处有多远，即TCP报文段的首部长度。
保留：占6位，保留今后使用。有6个控制位（TCP Flags）表示本报文段的性质。如下:
URG:紧急指针标志。当URG=1，表明紧急字段有效，应尽快传送。
ACK：确认序号标志。仅当ACK=1确认号字段才有效。
PSH：推送，push标志。发送方PSH=1，并立即创建一个报文段发送出去。
RST：服务，重置连接标志。当RST=1，表明TCP连接出现严重错误，必须释放连接。
SYN：同步序号，用于建立连接过程。SYN=1,ACK=0,建立连接请求；SYN=1,ACK=1,同意连接请求。
FIN：终止，finish标志。FIN=1，表明数据发送完毕，请求断开连接。
窗口：占2字节，窗口值作为接收方让发送方设置其发送窗口的依据。
校验和：占2字节。
紧急指针：占2字节，仅当URG=1时有效。
选项：长度可变，最长可达40字节。

TCP三次握手的全过程：
“握手”是为了建立连接，

三次握手
首先Client端发送连接请求报文，进入SYN-SEND状态，Server段接受连接后回复ACK报文，进入SYN-RCVD状态，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。
3次握手：
第一次握手：客户端尝试连接服务器，向服务器发送syn包（同步序列编号包），syn=j，客户端进入SYN_SEND状态等待服务器确认；
第二次握手：服务器接收到客户端的syn包并确认（ack=j+1），同时向客户端发送一个syn包（syn=k），即syn+ack包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的syn+ack包，向服务器发送确认包ack（ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

3、为什么要三次握手来建立连接？

为了防止已失效的连接请求报文段突然又传送到了服务端。假如A发出的一个连接请求因为网络的原因滞留在网络中，但是A因为长时间没有收到B发送过来的确认报文又重新发送了连接请求并传送数据，而A发出的第一个请求延迟了一段时间才到达B。本来这是一个已经失效的报文，但是B收到后以为A又发起的新的连接请求。于是就向A重新发送确认，建立连接。假如不采用三次握手，只要B发出确认连接就建立了，但是此时A并没有数据发送，并不会理睬B，但是B会一直等待A发送数据，B的很多资源就浪费了。
首次握手的隐患–SYN超时。
问题起因分析：
1、Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认；
2、Server不断重试直至超时，Linux默认等待63秒才断开连接。
针对SYN Flood的防护措施
1、SYN队列满后，通过tcp_syncookies参数回发SYN Cookie；
2、若为正常连接则Client会回发SYN Cookie，直接建立连接。
建立连接后，Client出现故障怎么办？
1、向对方发送保活探测报文，如果未收到响应则继续发送；
2、尝试次数达到保活探测数仍未收到响应则中断连接。

4、TCP四次挥手的全过程：

四次挥手是为了终止连接。
假设Client端（主动方）发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，“告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，“告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，“就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

四次挥手的流程：
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态；
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态；
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，，Server进入LAST_ACK状态；
第四次握手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
为什么会有TIME_WAIT状态？
1、确保有足够的时间让对方收到ACK包；
2、避免新旧连接混淆。

5、为什么要四次挥手才能够断开连接？

由于TCP是全双工通信的，因此每个方向上都必须单独进行关闭。关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
服务器出现大量CLOSE_WAIT状态的原因？
1、检查代码，特别是释放资源的代码；
2、检查配置，特别是处理请求的线程配置。

6、简述TCP和UDP的区别？

主要从1、有无连接；2可靠性；3、有序性；4、速度；5、量级五个方面产生区别；
UDP的特点：
1、面向非连接；
2、不维护连接状态，支持同时向多个客户端传输相同的消息；
3、数据包报头只有8个字节，额外开销较小；
4、吞吐量只受限于数据生成速率、传输速率以及机器性能；
5、尽最大努力交付，不保证可靠交付，不需要维持复杂的链接状态表；
6、面向报文，不对应用程序提交的报文信息进行拆分或者合并。
UDP（用户数据报协议 User Datagram Protocol）是面向无连接的、尽最大努力交付、不可靠的数据报服务。
没有拥塞控制；支持一对一、一对多、多对一和多对多；
TCP（传输控制协议 Transmission Control Protocol）是面向连接的、可靠的、字节流服务。
拥塞控制；全双工；
UDP主要用于对高速传输和实时性有较高要求的通信或广播通信，如
（1）包总量较少的通信（DNS、SNMP等）
（2）视频、音频等多媒体通信（即时通信），一方面因为它常常涉及到网络穿透，另外一方面它不需要重传。
（3）现定于LAN等特定网络中的应用通信
（4）广播通信（广播、多播）

7、http响应码301和302代表的是什么？有什么区别？

共同点：301响应码和302响应码都表示重定向（redirect），就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址 A瞬间变成了另一个地址B）
不同点：301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；
302表示旧地址A的资源还在（仍然可以访问），这个歌重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存就得网址。
301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。
301 redirect: 301 代表永久性转移(Permanently Moved)

302 redirect: 302 代表暂时性转移(Temporarily Moved )

8、forward与redirect的区别？

直接转发方式（forward），客户端和浏览器只发出一次请求，Servlet、HTML、jsp或其他信息资源，由第二个信息资源响应该请求，在请求对象request中，保存的对象对于每个信息资源是共享的。
间接转发方式（redirect），实际是两次HTTP请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。
举个例子就是：
直接转发：a找b借钱，b说没有，b去找c借，借到借不到都会把消息传递给a；
间接转发：a找b借钱，b说没有，让a去找c借。

forward是服务器内部重定向，程序收到请求后重新定向到另一个程序，客户机并不知道；redirect则是服务器收到请求后发送一个状态头给客户，客户将再请求一次，这里多了两次网络通信的来往。当然forward也有缺点，就是forward的页面的路径如果是相对路径就会有些问题了。forward会将request state ,bean等等信息带往下一个jsp。redirect是送到client端后再一次request,所以资料不被保留.使用forward你就可以用getAttribute()来取的前一个jsp所放入的bean等等资料。
在网上看到一些帖子，总结了一些区别，可以从以下几个方面来看：
1.从地址栏显示来说

forward是服务器请求资源，服务器直接访问目标地址的URL，把那个URL的响应内容读取过来，然后把这些内容再发给浏览器，浏览器根本不知道服务器发送的内容从哪里来的，所以它的地址栏还是原来的地址。
　　redirect是服务端根据逻辑，发送一个状态码，告诉浏览器重新去请求那个地址，所以地址栏显示的是新的URL.所以redirect等于客户端向服务端发出两次request，同时也接受两次response。

2.从数据共享来说

forword：转发页面和转发到的页面可以共享request里面的数据。
　　redirect：不能共享数据。
　　forward:转发页面和转发到的页面可以共享request里面的数据.
　　redirect:不能共享数据.

redirect不仅可以重定向到当前应用程序的其他资源,还可以重定向到同一个站点上的其他应用程序中的资源,甚至是使用绝对URL重定向到其他站点的资源.forward,方法只能在同一个Web应用程序内的资源之间转发请求.forward 是服务器内部的一种操作.redirect 是服务器通知客户端,让客户端重新发起请求.所以,你可以说 redirect是一种间接的请求, 但是你不能说"一个请求是属于forward还是redirect "
　　
3.从运用地方来说

forward：一般用于用户登录的时候，根据角色转发到相应的模块。
　　redirect：一般用于用户注销登录时返回主页面和跳转到其它的网站等。

4.从效率来说
　　forward:高.
　　redirect:低.

9、get和post请求有哪些区别？

最直观的区别：get把参数包含在URL中，而post用request body来传递参数。
两者的区别：
1、get在浏览器回退时是无害的，而post会再次提交请求。
2、get产生的URL地址可以被Bookmark（网摘），而post不可以。
3、get请求会被浏览器主动cache（高速缓冲处理器），而post不会，除非手动设置
4、get请求只能进行url编码，而post支持多种编码方式。
5、get请求参数会被完整保留在浏览器历史记录里，而post中的参数不会被保留。
6、get请求在url中传送的参数是有长度限制的，而post没有。
7、对参数的数据类型，get只接受ASCII字符，而post没有限制。
8、get比post更不安全，因为参数直接暴露在url上，所以不能用来传递敏感信息。
9、get参数通过url传递，post放在request body中。

但扒开get和post的本质，发现二者并没有什么区别。
get和post本质上都是HTTP协议中发送请求的方法。
而http是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
HTTP的底层是TCP/IP。所以get和post的底层也是TCP/IP,也就是说，get和post都是TCP链接。get和post能做的事情是一样的，如果非要给get加上request body，给post带上url参数，技术上是完全性的通的。

在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。
在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，**（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。**超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。
GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

get请求和post请求还有一个重大区别：
get：只产生一个TCP数据包；对于get方式的请求，浏览器会把http header和打他一并发送出去，服务器响应200（返回数据）；
post：post产生两个TCP数据包。对于post方式的请求，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？
1、get和post都有自己的语义，不能随便混用。
2、据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
3、并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

10、什么是跨域？如何实现跨域？

同源策略：浏览器的一种安全策略，也就是说a网站不能随便读取b网站的内容。同源指协议、端口号，域名相同。
跨域：
http://www.aaa.com:8080/script.js。这个我们平时经常见到的就是域名地址。把地址拆分：
http://——————–协议
www————————-子域名
aaa.com——————–主域名
8080————————端口号
script.js—————–请求资源地址
域名就由这五个部分组成，其中，当协议、子域名、主域名、端口号中任意一个不同时，都算作不同域；当不同域之间相互请求资源时，就算作“跨域”。
为什么会出现跨域问题？
安全问题！！！主要就是防止CSRF（跨站请求伪造）攻击，所以JavaScript处于安全方面的考虑，不允许跨域调用其他页面的对象。
跨域问题的处理方式？
1、代理：通过在同域名的web服务器端创建一个代理。比如：在A的web服务器后台调用B服务器的服务，然后把响应的结果返回给前端；
2、JSONP（重点）：在资源加载进来之前定义好一个函数，这个函数接收一个参数（数据），函数里面利用这个参数做一些事情，然后需要的时候通过script标签加载对应远程文件资源，当远程的文件资源被加载进来的时候，就回去执行我们前面定义好的函数，并且把数据当做这个函数的参数传入进去。
3、XHR2：在服务器端加上：header(‘Access-Control-Allow-Origin:*’);header(‘Access-Control-Allow-Methods:POST,GET’)。

11、说一下JSONP的实现原理？

首先提一下JSON这个概念，JSON是一种轻量级的数据传输格式，被广泛应用于当前Web应用中。JSON格式数据的编码和解析基本在所有主流语言中都被实现，所以现在大部分前后端分离的架构都以JSON格式进行数据的传输。

那么JSONP是什么呢？
首先抛出浏览器同源策略这个概念，为了保证用户访问的安全，现代浏览器使用了同源策略，即不允许访问非同源的页面，详细的概念大家可以自行百度。这里大家只要知道，在ajax中，不允许请求非同源的URL就可以了，比如www.a.com下的一个页面，其中的ajax请求是不允许访问www.b.com/c.php这样一个页面的。

JSONP就是用来解决跨域请求问题的，那么具体是怎么实现的呢？
原文：https://blog.csdn.net/u011897301/article/details/52679486
原文：https://blog.csdn.net/HansExploration/article/details/80314948

12、说一下tcp粘包是怎么产生的？

在学习java NIO时，如果客户端连续不断的向服务端发送数据时，服务端接收的数据会出现两个数据包粘在一起的情况，这就是TCP协议中经常会遇到的粘包以及拆包的问题。
TCP是属于传输层的协议，传输层除了有TCP协议之外还有UDP协议。那么为什么TCP协议会产生粘包拆包现象，而UDP协议不会呢？因为UDP协议是基于消息的传输服务，传输的是数据报，是有边界的，从UDP的帧结构可以看出，在UDP的首部采用了16bit来指示UDP数据报文的长度，因此应用层可以很好的将不同的数据报区分开，避免粘包和拆包的问题。
而TCP是基于字节流的传输，是没有边界的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块看成了一连串无结构的字节流，没有边界；从TCP的帧结构可以看出，在TCP的首部没有表示数据长度的字段，所以，在使用TCP传输数据时，会出现粘包拆包的现象。
TCP粘包和拆包的原因？
1、要发送的数据大于TCP发送缓冲区剩余空间的大小，将会发生拆包。
2、待发送的数据大于MSS（最大报文段长度），TCP在传输前将进行拆包。MSS：是报文段中数据字段的最大长度；即：MSS = TCP报文段最大长度-TCP首部长度
3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
TCP默认使用Nagle算法，而Nagle算法主要做两件事：1、只有上一个分组得到确认，才会发送下一个分组；2、收集多个小分组，在一个确认到来时一起发送。所以，Nagle算法的这些特点造成了发送方有可能造成粘包现象。

TCP在接收到分组后，不会立即送到应用层去处理，会先放到缓存区中，然后应用层会主动到缓存区来读取分组，这样以来，如果TCP接受分组的速度大于应用层读取分组的速度，就会有多个包存在缓存中，就可能会发生粘包现象。

粘包解决方案：
本质上是要在应用层维护消息与消息的边界
1、定长包（对等待接收的数据包以定长的方式接收）；
2、在包的尾部加上\r、\n等字符（如果包的内容也包含\r、\n，需要用转义字符\处理）
3、在包头加上包体的长度（接收时先接收包头，根据包头计算出包体的长度来接收包体）
4、更复杂的应用层协议。

13、cookie与session的区别？

具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。
cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式
session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。
保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。
经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：

实际上这种技术可以简单的用对action应用URL重写来代替