计算机网络

最新推荐文章于 2024-09-10 18:40:51 发布

hezuo1181

最新推荐文章于 2024-09-10 18:40:51 发布

阅读量627

点赞数

分类专栏： Java面试记录

Java面试记录专栏收录该内容

48 篇文章 1 订阅

订阅专栏

越努力越幸运！

深度好文！

网络通信过程及实践

2.3.1 TCP三次握手和四次挥手

明显三次握手是建立连接，四次挥手是断开连接，总图如下：

2.3.1.1 握手

（1）首先，Client端发送连接请求报文（SYN=1，seq=client_isn）

（2）Server段接受连接后回复ACK报文，并为这次连接分配资源。（SYN=1，seq=client_isn，ack = client_isn+1）

（3）Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。（SYN=0，seq=client_isn+1，ack = server_isn+1）

三次握手过程如下图所示：

2.3.1.2 挥手

注意：
中断连接端可以是Client端，也可以是Server端。

（1）假设Client端发起中断连接请求，也就是发送FIN报文。

（2） Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以 Server 端会先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。

这个时候Client端就进入 FIN_WAIT 状态，继续等待Server端的FIN报文。

（3）当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。

（4）Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传“，Server端收到ACK后，"就知道可以断开连接了"。

Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

注意：

（1）2个wait状态，FIN_WAIT和TIME_WAIT

（2）如果是Server端发起，过程反过来，因为在挥手的时候c和s在对等位置。

2.3.1.3 握手挥手状态图

Client端所经历的状态如下：

Server端所经历的过程如下：

2.3.1.4 注意问题

1、在TIME_WAIT状态中，如果TCP client端最后一次发送的ACK丢失了，它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭，并且所有的资源(包括端口号)都被释放。

2、为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

3、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

2.3.1.5 附：报文详解

TCP报文中的SYN,FIN,ACK,PSH,RST,URG

TCP的三次握手是怎么进行的：发送端发送一个SYN=1，ACK=0标志的数据包给接收端，请求进行连接，这是第一次握手；接收端收到请求并且允许连接的话，就会发送一个SYN=1，ACK=1标志的数据包给发送端，告诉它，可以通讯了，并且让发送端发送一个确认数据包，这是第二次握手；最后，发送端发送一个SYN=0，ACK=1的数据包给接收端，告诉它连接已被确认，这就是第三次握手。之后，一个TCP连接建立，开始通讯。

*SYN：同步标志
同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把 TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

*ACK：确认标志
确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

*RST：复位标志
复位标志有效。用于复位相应的TCP连接。

*URG：紧急标志
紧急(The urgent pointer) 标志有效。紧急标志置位

*PSH：推标志
该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。

*FIN：结束标志
带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。

TCP的几个状态对于我们分析所起的作用
在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG.其中，对于我们日常的分析有用的就是前面的五个字段。它们的含义是：SYN表示建立连接，FIN表示关闭连接，ACK表示响应，PSH表示有 DATA数据传输，RST表示连接重置。其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表示的只是建立连接。

TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。

详见：http://blog.csdn.net/scythe666/article/details/50967632

tcp的状态
http://www.cnblogs.com/qlee/archive/2011/07/12/2104089.html
http://www.2cto.com/net/201209/157585.html

2.3.2 Socket通信

套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。

套接字对是一个四元组，（local ip, local port, remote ip, remote port），通过这一四元组，唯一确定了网络通信的两端（两个进程或线程），ip地址确定主机，端口确定进程。

经典的在同一台主机上两个进程或线程之间的通信通过以下三种方法

管道通信（Pipes）
消息队列（Message queues）
共享内存通信（Shared memory）
这里有许多其他的方法，但是上面三中是非常经典的进程间通信。

详见：http://blog.csdn.net/violet_echo_0908/article/details/49539593

socket编程实例：

详见：http://www.cnblogs.com/linzheng/archive/2011/01/23/1942328.html

2.3.3 Http

HTTP协议是无状态的，同一个客户端的这次请求和上次请求是没有对应关系，对http服务器来说，它并不知道这两个请求来自同一个客户端。为了解决这个问题， Web程序引入了Cookie机制来维护状态.

Http响应

在接收和解释请求消息后，服务器返回一个HTTP响应消息。
HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

1、状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
eg：HTTP/1.1 200 OK （CRLF）

2、响应报头

3、响应正文就是服务器返回的资源的内容

详见：（1）http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html
（2）http://kb.cnblogs.com/page/130970/#statelesshttp

(3http://www.liaoxuefeng.com/wiki/001374738125095c955c1e6d8bb493182103fac9270762a000/001386832653051fd44e44e4f9e4ed08f3e5a5ab550358d000

--------------------- 本文来自 This is bill 的CSDN 博客，全文地址请点击：https://blog.csdn.net/Scythe666/article/details/52053100?utm_source=copy

1、Http和Https的区别

　　Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，而证书一般需要向认证机构购买；
　
Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

2、对称加密与非对称加密

　　对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

　　由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

3、三次握手与四次挥手

　(1). 三次握手(我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功)：

第一次握手：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之间可以开始传输数据了。

　(2). 四次挥手(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)：

第一次挥手：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状态，完成四次挥手。

4、为什么TCP链接需要三次握手，两次不可以么，为什么？

　　为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。

　　客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达Server。这是，Server误以为这是Client发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。若不采用“三次握手”，那么只要Server发出确认数据包，新的链接就建立了。由于client此时并未发出建立链接的请求，所以其不会理睬Server的确认，也不与Server通信；而这时Server一直在等待Client的请求，这样Server就白白浪费了一定的资源。若采用“三次握手”，在这种情况下，由于Server端没有收到来自客户端的确认，则就会知道Client并没有要求建立请求，就不会建立链接。

5、TCP协议如何来保证传输的可靠性

　　TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。

　　对于可靠性，TCP通过以下方式进行保证：

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

6、客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？

　　服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认

1)、DDos 攻击

客户端向服务端发送请求链接数据包
服务端向客户端发送确认数据包
客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

2)、DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )

限制同时打开SYN半链接的数目
缩短SYN半链接的Time out 时间
关闭不必要的服务

7、Get与POST的区别

　　GET与POST是我们常用的两种HTTP Method，二者之间的区别主要包括如下五个方面：

(1). 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；

(2). 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；

(3). 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的请求体中。

(4). 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。

(5). 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

1). GET请求中URL编码的意义

　　我们知道，在GET请求中会对URL中非西文字符进行编码，这样做的目的就是为了 避免歧义。看下面的例子，

　　针对“name1=value1&name2=value2”的例子，我们来谈一下数据从客户端到服务端的解析过程。首先，上述字符串在计算机中用ASCII吗表示为：

   6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
   6E616D6531：name1 
   3D：= 
   76616C756531：value1 
   26：&
   6E616D6532：name2 
   3D：= 
   76616C756532：value2

　　服务端在接收到该数据后就可以遍历该字节流，一个字节一个字节的吃，当吃到3D这字节后，服务端就知道前面吃得字节表示一个key，再往后吃，如果遇到26，说明从刚才吃的3D到26子节之间的是上一个key的value，以此类推就可以解析出客户端传过来的参数。

　　现在考虑这样一个问题，如果我们的参数值中就包含=或&这种特殊字符的时候该怎么办？比如，“name1=value1”，其中value1的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。这样，我们的本意是只有一个键值对，但是服务端却会解析成两个键值对，这样就产生了歧义。

　　那么，如何解决上述问题带来的歧义呢？解决的办法就是对参数进行URL编码：例如，我们对上述会产生歧义的字符进行URL编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在“%”后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符。更多关于 URL编码 的内容，请参考我的博文《使用 URLDecoder 和 URLEncoder 对中文字符进行编码和解码》，此不赘述。

8、TCP与UDP的区别

　　TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议，它们之间的区别包括：

TCP是面向连接的，UDP是无连接的；
TCP是可靠的，UDP是不可靠的；
TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；
TCP是面向字节流的，UDP是面向报文的；
TCP有拥塞控制机制;UDP没有拥塞控制，适合媒体通信；
TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；

9、TCP的拥塞处理

　　计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。拥塞控制的方法主要有以下四种：

1). 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;

2). 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。

　　　　　　　　　　慢开始与拥塞避免.png-90.3kB

3). 快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

　　　　　　　　　　快重传.jpg-42.3kB

4). 快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

　　　　　　　　　　快恢复.jpg-52.9kB

10、从输入网址到获得页面的过程

　　(1). 浏览器查询 DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；

　　(2). 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；

　　(3). TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；

　　(4). 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；

　　(5). 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；

　　(6). 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

11、Session、Cookie 与 Application

　　Cookie和Session都是客户端与服务器之间保持状态的解决方案，具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

(1). Cookie及其相关API

　　Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie，而客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

　　　　　　　　　　　 Cookoe-HttpServletResponse.png-38.6kB

　　　　　　　　　　　 HttpServletrequest-cookie.png-8.6kB

(2). Session及其相关API

　　同样地，会话状态也可以保存在服务器端。客户端请求服务器，如果服务器记录该用户状态，就获取Session来保存状态，这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用；如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。保存这个sessionid的方式可以采用 cookie机制，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器；若浏览器禁用Cookie的话，可以通过 URL重写机制将sessionid传回服务器。

　　　　　　　　　　　 Session-HttpServletRequest.png-10.1kB

(3). Session 与 Cookie 的对比

实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID；
大小限制：Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制，Session没有大小限制，理论上只与服务器的内存大小有关；
安全性：Cookie存在安全隐患，通过拦截或本地文件找得到cookie后可以进行攻击，而Session由于保存在服务器端，相对更加安全；
服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。

Application（ServletContext）：与一个Web应用程序相对应，为应用程序提供了一个全局的状态，所有客户都可以使用该状态。

(4). Application

　　Application（Java Web中的ServletContext）：与一个Web应用程序相对应，为应用程序提供了一个全局的状态，所有客户都可以使用该状态。

12、SQL 注入

　　SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

1). SQL注入攻击的总体思路

　　(1). 寻找到SQL注入的位置
　　(2). 判断服务器类型和后台数据库类型
　　(3). 针对不通的服务器和数据库特点进行SQL注入攻击

2). SQL注入攻击实例

　　比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：

用户名： ‘or 1 = 1 --
密 码：

　　用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?下面我们分析一下：从理论上说，后台认证程序中会有如下的SQL语句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，当输入了上面的用户名和密码，上面的SQL语句变成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL语句我们知道，
username=‘ or 1=1 这个语句一定会成功；然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。

3). 应对方法

(1). 参数绑定

　　使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中，对于传递的参数我们一般是使用#和$来获取参数值。当使用#时，变量是占位符，就是一般我们使用javajdbc的PrepareStatement时的占位符，所有可以防止sql注入；当使用$时，变量就是直接追加在sql中，一般会有sql注入问题。

(2). 使用正则表达式过滤传入的参数

13、 XSS 攻击

　　XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

1). XSS攻击的危害

盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
盗窃企业重要的具有商业价值的资料
非法转账
强制发送电子邮件
网站挂马
控制受害者机器向其它网站发起攻击

2). 原因解析

　　主要原因：过于信任客户端提交的数据！

　　解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

　　进一步分析细节：客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！！！

3). XSS 攻击分类

(1). 反射性XSS攻击 (非持久性XSS攻击)

　　漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)，例如，正常发送消息：

http://www.test.com/message.php?send=Hello,World！

接收者将会接收信息并显示Hello,World；但是，非正常发送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息显示的时候将会弹出警告窗口！

(2). 持久性XSS攻击 (留言板场景)

　　XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。与非持久性XSS攻击相比，持久性XSS攻击危害性更大。从名字就可以了解到，持久性XSS攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

例如，留言板表单中的表单域：

<input type=“text” name=“content” value=“这里是用户填写的数据”>

正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示；而非正常操作流程是攻击者在value填写:

<script>alert(‘foolish!’)；</script> <!--或者html其他标签（破坏样式。。。）、一段攻击型代码-->

并将数据提交、存储到数据库中；当其他用户取出数据显示的时候，将会执行这些攻击性代码。

4). 修复漏洞方针

　　漏洞产生的根本原因是太相信用户提交的数据，对用户所提交的数据过滤不足所导致的，因此解决方案也应该从这个方面入手，具体方案包括：

将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能
获取到cookie了（如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击）；
表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合。。。。
对数据进行Html Encode 处理
过滤或移除特殊的Html标签，例如: <script>, <iframe> , < for <, > for>, &quot for
过滤JavaScript 事件的标签，例如 “οnclick=”, “onfocus” 等等。

　　需要注意的是，在有些应用中是允许html标签出现的，甚至是javascript代码出现。因此，我们在过滤数据的时候需要仔细分析哪些数据是有特殊要求（例如输出需要html代码、javascript代码拼接、或者此表单直接允许使用等等），然后区别处理！

14、OSI网络体系结构与TCP/IP协议模型

　　为了更好地了解计算机网络体系结构，笔者以两篇博客的篇幅来介绍这个计算机网络中最为重要的知识点，具体见《计算机网络体系结构综述（上）》和《计算机网络体系结构综述（下）》。下面只做简要的总结。

　　在《计算机网络体系结构综述（下）》一文中，我们知道TCP/IP与OSI最大的不同在于：OSI是一个理论上的网络通信模型，而TCP/IP则是实际上的网络通信标准。但是，它们的初衷是一样的，都是为了使得两台计算机能够像两个知心朋友那样能够互相准确理解对方的意思并做出优雅的回应。现在，我们对OSI七层模型的各层进行简要的介绍：

　　　　　　　　　　 OSI网络体系结构与TCPIP协议模型.png-51.3kB

1). 物理层

　　参考模型的最低层，也是OSI模型的第一层，实现了相邻计算机节点之间比特流的透明传送，并尽可能地屏蔽掉具体传输介质和物理设备的差异，使其上层(数据链路层)不必关心网络的具体传输介质。

2). 数据链路层（data link layer）

　　接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层。这一层在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。

3). 网络层

　　将网络地址翻译成对应的物理地址，并通过路由选择算法为分组通过通信子网选择最适当的路径。

　　　　　　　　　　数据链路层与网路层.png-58.4kB

4). 传输层（transport layer）

　　在源端与目的端之间提供可靠的透明数据传输，使上层服务用户不必关系通信子网的实现细节。在协议栈中，传输层位于网络层之上，传输层协议为不同主机上运行的进程提供逻辑通信，而网络层协议为不同主机提供逻辑通信，如下图所示。

　　　　　　　　　　网路层与传输层.png-52.8kB

　　实际上，网络层可以看作是传输层的一部分，其为传输层提供服务。但对于终端系统而言，网络层对它们而言是透明的，它们知道传输层的存在，也就是说，在逻辑上它们认为是传输层为它们提供了端对端的通信，这也是分层思想的妙处。

5). 会话层（Session Layer）

　　会话层是OSI模型的第五层，是用户应用程序和网络之间的接口，负责在网络中的两节点之间建立、维持和终止通信。

6). 表示层（Presentation Layer）：数据的编码，压缩和解压缩，数据的加密和解密

　　表示层是OSI模型的第六层，它对来自应用层的命令和数据进行解释，以确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。

7). 应用层（Application layer）：为用户的应用进程提供网络通信服务

15、TCP和UDP分别对应的常见应用层协议

1). TCP对应的应用层协议

FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。
SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
HTTP：从Web服务器传输超文本到本地浏览器的传送协议。

2). UDP对应的应用层协议

DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

3). 图示

　　　　　　　　　　 TCP和UDP分别对应的常见应用层协议.png-41.5kB

16、网络层的ARP协议工作原理

　　网络层的ARP协议完成了IP地址与物理地址的映射。首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址：如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址；源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

17、IP地址的分类

　　IP地址是指互联网协议地址，是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP地址编址方案将IP地址空间划分为A、B、C、D、E五类，其中A、B、C是基本类，D、E类作为多播和保留使用，为特殊地址。

　　每个IP地址包括两个标识码（ID），即网络ID和主机ID。同一个物理网络上的所有主机都使用同一个网络ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机ID与其对应。A~E类地址的特点如下：

A类地址：以0开头，第一个字节范围：0~127；
B类地址：以10开头，第一个字节范围：128~191；
C类地址：以110开头，第一个字节范围：192~223；
D类地址：以1110开头，第一个字节范围为224~239；
E类地址：以1111开头，保留地址

1). A类地址：1字节的网络地址 + 3字节主机地址，网络地址的最高位必须是“0”

　　一个A类IP地址是指，在IP地址的四段号码中，第一段号码为网络号码，剩下的三段号码为本地计算机的号码。如果用二进制表示IP地址的话，A类IP地址就由1字节的网络地址和3字节主机地址组成，网络地址的最高位必须是“0”。A类IP地址中网络的标识长度为8位，主机标识的长度为24位，A类网络地址数量较少，有126个网络，每个网络可以容纳主机数达1600多万台。

　　A类IP地址的地址范围1.0.0.0到127.255.255.255（二进制表示为：00000001 00000000 00000000 00000000 - 01111110 11111111 11111111 11111111），最后一个是广播地址。A类IP地址的子网掩码为255.0.0.0，每个网络支持的最大主机数为256的3次方-2=16777214台。

2). B类地址: 2字节的网络地址 + 2字节主机地址，网络地址的最高位必须是“10”

　　一个B类IP地址是指，在IP地址的四段号码中，前两段号码为网络号码。如果用二进制表示IP地址的话，B类IP地址就由2字节的网络地址和2字节主机地址组成，网络地址的最高位必须是“10”。B类IP地址中网络的标识长度为16位，主机标识的长度为16位，B类网络地址适用于中等规模的网络，有16384个网络，每个网络所能容纳的计算机数为6万多台。

　　B类IP地址地址范围128.0.0.0-191.255.255.255（二进制表示为：10000000 00000000 00000000 00000000—-10111111 11111111 11111111 11111111），最后一个是广播地址。B类IP地址的子网掩码为255.255.0.0，每个网络支持的最大主机数为256的2次方-2=65534台。

3). C类地址: 3字节的网络地址 + 1字节主机地址，网络地址的最高位必须是“110”

　　一个C类IP地址是指，在IP地址的四段号码中，前三段号码为网络号码，剩下的一段号码为本地计算机的号码。如果用二进制表示IP地址的话，C类IP地址就由3字节的网络地址和1字节主机地址组成，网络地址的最高位必须是“110”。C类IP地址中网络的标识长度为24位，主机标识的长度为8位，C类网络地址数量较多，有209万余个网络。适用于小规模的局域网络，每个网络最多只能包含254台计算机。

　　C类IP地址范围192.0.0.0-223.255.255.255（二进制表示为: 11000000 00000000 00000000 00000000 - 11011111 11111111 11111111 11111111）。C类IP地址的子网掩码为255.255.255.0，每个网络支持的最大主机数为256-2=254台。

4). D类地址:多播地址，用于1对多通信，最高位必须是“1110”

　　D类IP地址在历史上被叫做多播地址(multicast address)，即组播地址。在以太网中，多播地址命名了一组应该在这个网络中应用接收到一个分组的站点。多播地址的最高位必须是“1110”，范围从224.0.0.0到239.255.255.255。

5). E类地址:为保留地址，最高位必须是“1111”

18、IP地址与物理地址

　　物理地址是数据链路层和物理层使用的地址，IP地址是网络层和以上各层使用的地址，是一种逻辑地址，其中ARP协议用于IP地址与物理地址的对应。

21、常见状态码及原因短语

　　HTTP请求结构：请求方式 + 请求URI + 协议及其版本
　　HTTP响应结构：状态码 + 原因短语 + 协议及其版本

1×× : 请求处理中，请求已被接受，正在处理

2×× : 请求成功，请求被成功处理
200 OK

3×× : 重定向，要完成请求必须进行进一步处理
301 : 永久性转移
302 ：暂时性转移
304 ：已缓存

4×× : 客户端错误，请求不合法
400：Bad Request,请求有语法问题
403：拒绝请求
404：客户端所访问的页面不存在

5×× : 服务器端错误，服务器不能处理合法请求
500 ：服务器内部错误
503 ：服务不可用，稍等

--------------------- 本文来自书呆子Rico 的CSDN 博客，全文地址请点击：https://blog.csdn.net/justloveyou_/article/details/78303617?utm_source=copy

本书所有测试网络例子

这里写图片描述

1、TCP/IP的分层

在图1 - 2的右边，我们注意到应用程序通常是一个用户进程，而下三层则一般在（操作系
统）内核中执行。尽管这不是必需的，但通常都是这样处理的，例如 U N I X操作系统。

在图1 - 2中，顶层与下三层之间还有另一个关键的不同之处。应用层关心的是应用程序的
细节，而不是数据在网络中的传输活动。下三层对应用程序一无所知，但它们要处理所有的
通信细节。

这里写图片描述

2、TCP/IP协议族

这里写图片描述

3、五类网络地址

这里写图片描述

区分各类地址的最简单方法是看它的第一个十进制整数，有三类I P地址：单播地址（目的为单个主机）、广播地址（目的端为给定网络上的所有主机）以及多播地址（目的端为同一组内的所有主机）

4、域名系统

在T C P / I P领域中，域名系统（D N S）是一个分布的数据库，由它来提供 I P地址和
主机名之间的映射信息。现在，我们必须理解，任何应用程序都可以调用一个标准的库函数来查看给定名字的主机的I P地址。类似地，系统还提供一个逆函数—给定主机的I P地址，查看它所对应的主机名。

大多数使用主机名作为参数的应用程序也可以把 I P地址作为参数。例如，在第 4章中当我们用Te l n e t进行远程登录时，既可以指定一个主机名，也可以指定一个 I P地址。

5、封装

当应用程序用T C P传送数据时，数据被送入协议栈中，然后逐个通过每一层直到被当作
一串比特流送入网络。其中每一层对收到的数据都要增加一些首部信息（有时还要增加尾部
信息），该过程如图1 - 7所示。T C P传给I P的数据单元称作 T C P报文段或简称为T C P段（T C P s e g m e n t）。I P传给网络接口层的数据单元称作I P数据报(IP datagram)。通过以太网传输的比特流称作帧(Fr a m e )。

更准确地说，图1 - 7中I P和网络接口层之间传送的数据单元应该是分组（ p a c k e t）。
分组既可以是一个I P数据报，也可以是I P数据报的一个片（f r a g m e n t）。我们将在11 . 5节讨论IP数据报分片的详细情况。

这里写图片描述

由于T C P、U D P、I C M P和I G M P都要向I P传送数据，因此I P必须在生成的I P首部中加入某种标识，以表明数据属于哪一层。为此， I P在首部中存入一个长度为8 b i t的数值，称作协议域。1表示为I C M P协议，2表示为I G M P协议，6表示为T C P协议，1 7表示为U D P协议。

6、解封装

这里写图片描述

为协议I C M P和I G M P定位一直是一件很棘手的事情。在图1 - 4中，把它们与I P放在
同一层上，那是因为事实上它们是I P的附属协议。但是在这里，我们又把它们放在I P层
的上面，这是因为ICMP和IGMP报文都被封装在IP数据报中。

7、重复型服务器 VS 并发型服务器

可以将这种服务分为两种类型：重复型或并发型。

（1）重复型服务器通过以下步骤进行交互：

I1. 等待一个客户请求的到来。
I2. 处理客户请求。
I3. 发送响应给发送请求的客户。
I4. 返回I 1步。
重复型服务器主要的问题发生在I 2状态。在这个时候，它不能为其他客户机提供服务。

（2）相应地，并发型服务器采用以下步骤：

C1. 等待一个客户请求的到来。
C2. 启动一个新的服务器来处理这个客户的请求。在这期间可能生成一个新的进程、任务
或线程，并依赖底层操作系统的支持。这个步骤如何进行取决于操作系统。生成的新服务器
对客户的全部请求进行处理。处理结束后，终止这个新服务器。
C3. 返回C 1步。
并发服务器的优点在于它是利用生成其他服务器的方法来处理客户的请求。也就是说，
每个客户都有它自己对应的服务器。如果操作系统允许多任务，那么就可以同时为多个客户
服务。

一般来说，T C P服务器是并发的，而 U D P服务器是重复的

8、tcp/udp端口

从该图可以看出，当使用 T C P和U D P提供相同的服务时，一般选择相同的端口号。

这里写图片描述

如果仔细检查这些标准的简单服务以及其他标准的 T C P / I P服务（如Te l n e t、F T P、
S M T P等）的端口号时，我们发现它们都是奇数。这是有历史原因的，因为这些端口号
都是从N C P端口号派生出来的（N C P，即网络控制协议，是A R PA N E T的运输层协议，
是T C P的前身）。N C P是单工的，不是全双工的，因此每个应用程序需要两个连接，需
预留一对奇数和偶数端口号。当T C P和U D P成为标准的运输层协议时，每个应用程序
只需要一个端口号，因此就使用了NCP中的奇数。

9、internet != Internet

i n t e r n e t这个词第一个字母是否大写决定了它具有不同的含义。

i n t e r n e t意思是用一个共同的协议族把多个网络连接在一起。而 I n t e r n e t指的是世界范围内通过T C P / I P互相通信的所有主机集合（超过1 0 0万台）。I n t e r n e t是一个i n t e r n e t，但i n t e r n e t不等于I n t e r n e t。

10、链路层三个基本问题（一）封装成帧

在一段数据的前后分别添加首部和尾部，这样就构成了一个帧。

这里写图片描述

11、链路层三个基本问题（二）透明传输

这里写图片描述

12、差错检查（CRC）

这里写图片描述

13、MTU

M T U是I P向链路层查询的结果，因此该值必须包括通常的 T C P和I P首部

我们使用M T U经常是因为它对I P数据报的长度进行限制，但一般与最小长度无关。

14、无连接

无连接（c o n n e c t i o n l e s s）这个术语的意思是I P并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。这也说明， I P数据报可以不按发送顺序接收。

15、IP首部

这里写图片描述

16、网络字节序

4个字节的32 bit值以下面的次序传输：首先是0～7 bit，其次8～15 bit，然后1 6～23 bit，
最后是24~31 bit。这种传输次序称作big endian字节序。由于T C P / I P首部中所有的二进制整数
在网络中传输时都要求以这种次序，因此它又称作网络字节序。以其他形式存储二进制整数
的机器，如little endian格式，则必须在传输数据之前把首部转换成网络字节序。

17、IP报头之：总长度字段

总长度字段是指整个I P数据报的长度，以字节为单位。利用首部长度字段和总长度字段，
就可以知道I P数据报中数据内容的起始位置和长度。由于该字段长 1 6比特，所以I P数据报最
长可达6 5 5 3 5字节（回忆图 2 - 5，超级通道的 M T U为6 5 5 3 5。它的意思其实不是一个真正的
M T U—它使用了最长的I P数据报）。当数据报被分片时，该字段的值也随着变化，这一点将
在11 . 5节中进一步描述。

18、576字节来源

默认MSS是536，加上tcp报头和IP报头，就是576

19、路由表长什么样

这里写图片描述

20、路由的原理

这里写图片描述

21、目的IP不变，MAC地址总在改变

当数据报从b s d i被传到s u n主机上以后，目的I P地址是最终的信宿机地
址（1 9 2 . 4 8 . 9 6 . 9），但是链路层地址却是s u n主机的以太网接口地址。

22、特殊的IP地址

这里写图片描述

23、ARP

A R P本来是用于广播网络的，有许多主机或路由器连在同一个网络上。

这里写图片描述

点对点链路不使用A R P。当设置这些链路时（一般在引导过程进行），必须告知内核链路每一端的I P地址。像以太网地址这样的硬件地址并不涉及。

24、免费ARP

这里写图片描述

免费A R P可以有两个方面的作用：

1) 一个主机可以通过它来确定另一个主机是否设置了相同的 I P地址。主机b s d i并不希望
对此请求有一个回答。但是，如果收到一个回答，那么就会在终端日志上产生一个错误消息
“以太网地址：a : b : c : d : e : f发送来重复的I P地址” 。这样就可以警告系统管理员，某个系统有不正确的设置。

2) 如果发送免费A R P的主机正好改变了硬件地址（很可能是主机关机了，并换了一块接
口卡，然后重新启动），那么这个分组就可以使其他主机高速缓存中旧的硬件地址进行相应的
更新。一个比较著名的A R P协议事实[Plummer 1982]是，如果主机收到某个I P地址的A R P请求，
而且它已经在接收者的高速缓存中，那么就要用 A R P请求中的发送端硬件地址（如以太网地
址）对高速缓存中相应的内容进行更新。主机接收到任何 A R P请求都要完成这个操作（ A R P
请求是在网上广播的，因此每次发送A R P请求时网络上的所有主机都要这样做）。
文献[ B h i d e、E l n o z a h y和M o rgan 1991]中有一个应用例子，通过发送含有备份硬件地址和
故障服务器的I P地址的免费A R P请求，使得备份文件服务器可以顺利地接替故障服务器进行
工作。这使得所有目的地为故障服务器的报文都被送到备份服务器那里，客户程序不用关心
原来的服务器是否出了故障。

25、为什么ICMP协议没有端口概念

我们称发送回显请求的p i n g程序为客户，而称被p i n g的主机为服务器。大多数的T C P / I P实现都在内核中直接支持P i n g服务器—这种服务器不是一个用户进程，所以ping没有端口。

其他icmp协议同上

26、ICMP报文类型

这里写图片描述

27、udp首部

这里写图片描述

28、udp端口 VS tcp端口

T C P端口号与U D P端口号是相互独立的。尽管相互独立，如果T C P和U D P同时提供某种知名服务，两个协议通常选择相同的端口号。这纯粹是为了使用方便，而不是协议本身的要求。

29、udp伪首部

这里写图片描述

30、udp校验和

U D P检验和覆盖U D P首部和U D P数据。回想I P首部的检验和，它只覆盖I P的首部—并不
覆盖I P数据报中的任何数据。

U D P和T C P在首部中都有覆盖它们首部和数据的检验和。 U D P的检验和是可选的，而T C P的检验和是必需的。

尽管U D P检验和的基本计算方法与我们在 3 . 2节中描述的I P首部检验和计算方法相类似
（16 bit字的二进制反码和），但是它们之间存在不同的地方。首先， U D P数据报的长度可以为奇数字节，但是检验和算法是把若干个 16 bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。

31、IP分片

物理网络层一般要限制每次发送数据帧的最大长度。任何时候I P层接收到一份要发送的I P数据报时，它要判断向本地哪个接口发送数据（选路），并查询该接口获得其M T U。I P把M T U与数据报长度进行比较，如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上。

重新组装由目的端的I P层来完成，其目的是使分片和重新组装过程对运输层（ T C P和U D P）是透明的。

上面的话说明了，粘包的过程跟分片无关了

32、DNS 迭代查询 + 递归查询

这里写图片描述

33、一个DNS的例子

这里写图片描述

34、TCP提供字节流服务

两个应用程序通过T C P连接交换8 bit字节构成的字节流。T C P不在字节流中插入记录标识
符。我们将这称为字节流服务（byte stream service）。如果一方的应用程序先传1 0字节，又传2 0字节，再传5 0字节，连接的另一方将无法了解发方每次发送了多少字节。收方可以分 4次接收这8 0个字节，每次接收 2 0字节。一端将字节流放到 T C P连接上，同样的字节流将出现在T C P连接的另一端。

另外，T C P对字节流的内容不作任何解释。 T C P不知道传输的数据字节流是二进制数据，
还是A S C I I字符、E B C D I C字符或者其他类型数据。对字节流的解释由 T C P连接双方的应用层解释。

这种对字节流的处理方式与U n i x操作系统对文件的处理方式很相似。U n i x的内核
对一个应用读或写的内容不作任何解释，而是交给应用程序处理。对U n i x的内核来说，
它无法区分一个二进制文件与一个文本文件。

这里写图片描述

35、MSS后面可变吗

不可以，详见RFC 793

这里写图片描述

36、MSS在TCP头的哪里放着

在option可选部分

这里写图片描述

37、滑窗是在三次握手的哪里规定的

这里写图片描述

显示为第一次就在商量了

--------------------- 本文来自 This is bill 的CSDN 博客，全文地址请点击：https://blog.csdn.net/Scythe666/article/details/51992460?utm_source=copy

前言

作为一名程序员, 不可能不与网络打交道. 现在我们的手机, 电脑, 不夸张地说, 离开了网络就是一块’废铁’, 它们的作用将大打折扣.. 本文的作用呢, 主要是针对不是非网络专业开发的人员准备的, 以’最短的时间, 了解计网最多的知识’为前提起笔.

概述

先来了解下各种我们知道, 但是不太了解的专业名词的意思

因特网

因特网是当今世界上最大的网络, 是”网络的网络”. 即因特网是所有网络互连起来的一个巨型网络.

因特网的组成 :

边缘部分 : 主机
核心部分 : 大量网络和连接这些网络的路由器(此路由器不是我们家用的路由器)

以太网

以太网是现在最常用的局域网通信协议, 以太网上传输的是MAC帧. 由于以太网同一时间只允许一台计算机发送数据, 所以必须有一套检测机制, 那就是CSMA/CD协议 :

多点接入 : 多台计算机以多点接入的方式连接在一根总线上
载波监听 : 不管是否正在发送, 每个站都必须不停地检测信道
碰撞检测 : 边发送边监听

OSI

开放系统互连基本参考模型, 只要遵守这个OSI标准, 任何两个系统都能进行通信. OSI是七层协议体系结构, 而TCP/IP是一个四层协议体系结构, 于是我们采取折中的方法, 学习计算机网络原理的时候往往用的是五层协议的体系结构 : 物理层, 数据链路层, 网络层, 传输层和应用层

物理层

计算机的世界里只有0和1, 正如你现在所看这篇文章的文字, 存储在计算机中也是一大串0和1的组合. 但是这些数字不能在真实的物理介质中传输的, 而需要把它转换为光信号或者电信号, 所以这一层负责将这些比特流(0101)与光电信号进行转换.

如果没有物理层, 那么也就不存在互联网, 不存在数据的共享, 因为数据无法在网络中流动.

数据链路层

数据在这一层不再是以比特流的形式传输, 而是分割成一个一个的帧再进行传输.

MAC地址

又称计算机的硬件地址, 被固化在适配器(网卡)ROM上的占48位的地址. MAC地址可以用来唯一区别一台计算机, 因为它在全球是独一无二的

分组交换

由于数据在这次曾要被分割成一个一个的帧, 由于不同的链路规定了不同的最大帧长, 即MTU(最大传输单元), 凡是超出这个MTU的帧都必须被分块. 例如一台货车一次能运输5吨的货物, 而有条公路限载重2吨, 那么你只好分3次运输.

网桥

网桥工作在数据链路层, 根据MAC帧的目的地址对收到的帧进行转发和过滤.

以太网交换机

实际上就是一个多接口的网桥, 以太网交换机的每个接口都直接与一个单个主机或另一个集线器相连, 可以很容易实现VLAN(虚拟局域网)

以太网的MAC帧

MAC帧的格式为 :

目的地址 : 接收方48位的MAC地址
源地址 : 发送方48位的MAC地址
类型字段 : 标志上一层使用的是什么协议, 0×0800为IP数据报

网络层

如果只有数据链路层没有网络层, 数据就只能在同一条链路上传输, 不能跨链路传输. 有了网络层, 数据便能跨域不同的数据链路传输.

IP地址

IP地址又称为软件地址, 存储在计算机的存储器上, IPv4地址为32位, IPv6地址为128位

IP地址和MAC地址

网络层以上使用IP地址, 数据链路层以下使用MAC地址
IP地址是逻辑地址, MAC地址是物理地址
IP分组中首部的源地址和目的地址在传输中不会改变, MAC帧中首部的源地址和目的地址每到一个路由器会改变一次

IP地址分类

IP地址 = {<网络号>, <主机号>}

A类地址 : 0.0.0.0 ~ 127.0.0.0

B类地址 : 128.0.0.0 ~ 191.255.0.0

C类地址 : 192.0.0.0 ~ 223.255.255.0

划分子网之后的IP地址

IP地址 = {<网络号>, <子网号>, <主机号>}

例如某单位拥有一个B类IP地址, 145.13.0.0, 但凡目的地址为145.13.x.x的数据报都会被送到这个网络上的路由器R. 内部划分子网后变成 : 145.13.3.0, 145.13.7.0, 145.13.21.0. 但是对外仍表现为一个网络, 即145.13.0.0. 这样路由器R收到报文后, 再根据目的地址发到对应的子网上.

子网掩码

一般由一串1和一串0组成, 不管网络有没有划分子网, 将子网掩码和IP地址做按位与运算即可得出网络地址.

所有的网络都必须使用子网掩码, 同时在路由表中必须有子网掩码这一栏. 如果一个网络不划分子网, 那么该网络的子网掩码就是默认的子网掩码.

A类地址的默认子网掩码为255.0.0.0

B类地址的默认子网掩码为255.255.0.0

C类地址的默认子网掩码为255.255.255.0

尽管划分子网增加了灵活性, 但是却减少了能够连接在网络上的主机总数.

构成超网的IP地址

IP地址 = {<网络前缀>, <主机号>}

使用网络前缀, 无分类域间路由选择CIDR

例如, 128.14.35.7/20, 意思是前20位为网络前缀, 后12位为主机号. 另外, CIDR把网络前缀相同的连续的IP地址组成一个”CIDR地址块”

地址掩码 : CIDR使用32位的地址掩码, 类似于子网掩码.

IP数据报

在网络层, 数据是以IP数据报(IP分组)的形式传输的

首部前20字节为固定长度, 是所有IP数据报必备的. 后4字节是可选字段, 其长度可变.

IP数据报首部固定的字段分析 :

版本号 : IP协议的版本, IPv4或IPv6
首部长度 : 记录了首部的长度, 最大为1111, 即15个32位字长, 即60字节. 当首部长度不是4字节的整数倍时, 需要使用最后的填充字段加以填充.
服务类型 : 一般无用
总长度 : 指首部和数据之和的长度. 最大为216-1 = 65535字节. 但是由于数据链路层规定每一帧的数据长度都有最大长度MTU, 以太网规定MTU为1500字节, 所以超出范围的数据报就必须进行分片处理
标识 : 每产生一个IP数据报, 计数器就+1, 并将此值赋值给标识字段. 再以后需要分片的数据报中, 标识相同说明是同一个数据报
标志 : 占3位, 最低位记为MF(More Fragment). MF = 1说明还有分片; MF = 0说明这已经是最后一个分片. 中间一位记为DF(Don’t Fragment), 意思是不能分片. 只有当DF = 0时才允许分片.
段位移 : 又称片位移, 相对于用户数据字段的起点, 该片从何处开始. 片位移以8个字节为偏移单位. 所以, 每个分片的长度一定是8字节的整数倍.
生存时间 : TTL(Time To Live). 数据报能在因特网中经过路由器的最大次数为255次, 每经过一个路由器则TTL – 1, 为0时丢弃该报文.
协议 : 记录该报文所携带的数据是使用何种协议.
首部检验和 : 只检验数据报的首部, 不检验数据部分. 不为0则丢弃报文.
源地址和目的地址 : 不解释

IP层转发分组的流程

每个路由器内部都维护一个路由表, 路由表包含以下内容(目的网络地址, 下一跳地址).

使用子网时分组转发时, 路由表必须包含以下三项内容: 目的网络地址, 子网掩码和下一跳地址.

特定主机路由 : 对特定的目的地址指明一个路由

默认路由 : 不知道分组该发给哪个路由器时就发给默认路由. 当一个网络只有很少的对外连接时使用默认路由非常合适.

路由器的分组转发算法

从数据报中拿到目的IP地址D, 得出目的网络地址N
若N就是与此路由器直接相连的某个网络地址, 则直接交付(不需要再交给其他路由器转发, 直接找到该目的主机交付), 否则 -> (3)
若路由表中有目的地址为D的特定主机路由, 则把数据报传给该路由器, 否则 -> (4)
若路由表中有到达网络N的路由, 则把数据报传给该路由器, 否则 -> (5)
若路由表中有默认路由, 则交给该路由器, 否则 -> (6)
报告转发分组出错

虚拟专用网VPN

因特网中的所有路由器对该目的地址是专用地址的数据报一律不转发, 下面有3种专用地址(虚拟IP地址)

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

假设现在公司A有一个部门在广州和另一个在上海, 而他们在当地都有自己的专用网. 那么怎么将这两个专用网连接起来呢?

租用电信的通信线路为本机构专用, 但是太贵了
利用公用的因特网当做通信载体, 这就是虚拟专用网VPN

网络地址转换NAT

多个专用网内部的主机公用一个NAT路由器的IP地址, 在主机发送和接收IP数据报时必须先通过NAT路由器进行网络地址转换.

不仅如此, NAT还能使用端口号, 摇身一变成为网络地址和端口转换NAPT

ARP协议

ARP是解决同一个局域网上的主机或路由器的IP地址和MAC地址的映射问题, 即 IP地址 -> ARP -> MAC地址

每一个主机都有一个ARP高速缓存, 里面有本局域网上的各主机和路由器的IP地址到MAC地址的映射表. 以下是ARP的工作原理 :

那如果是跨网络使用ARP呢?

在本网络上广播
未找到该主机, 则到路由器
路由器帮忙转发(在另一网络上广播)
找到了则完成ARP请求, 未找到则返回(2)

传输层

这一层是重中之重, 因为数据链路层, 网络层这两层的数据传输都是不可靠的, 尽最大能力交付的. 什么意思的? 就是它们不负责提交给你的就是正确的数据. 然而这一层的TCP协议将要提供可靠传输

这一层主要重点是两个协议 : UDP 和 TCP

用户数据报协议UDP

UDP主要特点 :

无连接
尽最大努力交付
面向报文 : 应用层交下来的报文直接加上UDP头部就往IP层扔, 不合并也不拆分
没有拥塞控制
支持一对一, 一对多, 多对一和多对多的交互通信
首部开销小, 只有8个字节

UDP首部

源端口 : 源端口号. 在需要对方回信时选用, 不需要则全0
目的端口 : 目的端口号. 这在终点交付报文时必须要使用到
长度 : UDP数据报的长度, 最小值为8(仅有首部)
检验和 : 与IP数据报只检验首部不同的是, UDP需要把首部和数据部分一起检验

传输控制协议TCP

TCP主要特点 :

面向连接的运输层协议
每一条TCP连接只能有2个端点, TCP是点对点的
提供可靠交付
全双工通信
面向字节流

TCP的工作流程

TCP的连接

TCP连接的端点叫套接字(socket)

socket = (IP地址 : 端口号)

每一条TCP连接唯一地被通信两端的两个端点(socket)所确定. 即 :

TCP连接 ::= {socket1, socket2} = {(IP1 : port1), (IP2 : port2)}

TCP报文段的首部

源端口和目的端口 : 同UDP端口作用
序号 : 本报文段的数据的第一个字节的序号
确认号 : 期望收到对方下一个报文段的第一个数据字节的序号

若确认号 = N, 则表明 : 到序号N-1为止的所有数据都已正常收到

数据偏移 : TCP报文段的首部长度
保留 : 以后用, 目前为0
紧急URG : 若URG = 1时, 说明紧急指针字段有效, 告诉系统这是紧急数据, 应尽快传送. 例如突然要中断传送
确认ACK : ACK = 1时确认号才有效, ACK = 0时确认号无效. TCP规定, 连接建立后所有传送的报文段都必须把ACK置1
推送PSH : 若PSH = 1, 则接收方收到报文段之后不再等到整个缓存满而是直接向上交付
复位RST : 当RST = 1, 说明TCP连接有严重错误, 必须释放连接再重连
同步SYN : 在连接建立时用来同步序号. 当SYN = 1, ACK = 0时表明这是一个连接请求报文段, 对方若同意建立连接, 则在响应的报文段中置SYN = 1, ACK = 1
终止FIN : 当FIN = 1, 表明此报文段的发送方数据已发送完毕, 并要求释放连接
窗口 : 告诉对方 : 从本报文段首部中的确认号算起, 接收方目前允许对方发送的数据量. 这是作为接收方让发送方设置其发送窗口的依据
检验和 : 同UDP, 检验首部和数据部分
紧急指针 : 当URG = 1时有效, 指出紧急数据的末尾在报文段的位置
选项 : 最大可40字节, 没有则为0

最大报文段长度MSS(Maximum Segment Size) : 每一个TCP报文段中数据字段的最大长度, 若不填写则为默认的536字节.

窗口

TCP中很重要的一个概念, 那就是窗口(发送窗口和接收窗口)

由于停止等待协议非常低效, 于是衍生出窗口这一概念. 上图为发送方维持的发送窗口, 位于发送窗口的5个分组都可以连续发送出去而不需要等待对方的确认. 每收到一个确认, 就把发送窗口前移一个分组的位置. 这大大提高了信道利用率!

接收方不必发送每个分组的确认报文, 而是采用累积确认的方式. 也就是说, 对按序到达的最后一个分组发送确认报文.

超时重传

如果发送方等待一段时间后, 还是没收到 ACK 确认报文, 就会启动超时重传. 这个等待的时间为重传超时时间(RTO, Retransmission TimeOut).

然而, RTO 的值不是固定的, 这个时间总是略大于连接往返时间(RTT，Round Trip Time). 假设报文发送过去需要5秒, 对方收到后发送确认报文回来也需要5秒, 那么RTT就为10秒, 那这RTO就要比10秒要略大一些. 那么超过RTO之后还没有收到确认报文就认为报文丢失了, 就要重传.

流量控制

利用滑动窗口和报文段的发送时机来进行流量控制.

拥塞控制

发送方维持一个拥塞窗口cwnd, 发送窗口 = 拥塞窗口.

慢开始 : cwnd = 1, 然后每经过一个传输轮次就翻倍

拥塞避免 : 让cwnd缓慢增大, 每经过一个传输轮次就+1

慢开始门限ssthresh :

当cwnd < ssthresh, 使用慢开始算法当cwnd > ssthresh, 使用拥塞避免算法当cwnd = ssthresh, 随意

只要判断网络出现拥塞, 把ssthresh设为当前发送拥塞窗口的一半(不能小于2), 并把cwnd设为1, 重新执行慢开始算法.

除了慢开始和拥塞避免算法外, 还有一组快重传和快恢复算法 :

快重传 : 接收方及时发送确认, 而发送方只要一连收到三个重复确认, 马上重传

快恢复 : 当发送方一连收到三个重复确认时, ssthresh减半, cwnd设为ssthresh.

TCP三次握手

TCP三次握手建立连接和四次挥手断开连接是面试爱问的知识点.

Q : 为什么要三次握手, 两次不可以吗?

A : 试想一下, A第一次发送请求连接, 但是在网络某节点滞留了, A超时重传, 然后这一次一切正常, A跟B就愉快地进行数据传输了. 等到连接释放了以后, 那个迷失了的连接请求突然到了B那, 如果是两次握手的话, B发送确认, 它们就算是建立起了连接了. 事实上A并不会理会这个确认, 因为我压根没有要传数据啊. 但是B却傻傻地以为有数据要来, 苦苦等待. 结果就是造成资源的浪费.

更加接地气的解释就是 : A打电话给B

第一次握手 : 你好, 我是A, 你能听到我说话吗第二次握手 : 听到了, 我是B, 你能听到我说话吗第三次握手 : 听到了, 我们可以开始聊天了三次握手其实就是为了检测双方的发送和接收能力是否正常, 你说呢?

TCP四次挥手

Q : 为什么要四次挥手, 而不是两次, 三次?

A :

首先, 由于TCP的全双工通信, 双方都能作为数据发送方. A想要关闭连接, 必须要等数据都发送完毕, 才发送FIN给B. (此时A处于半关闭状态)

然后, B发送确认ACK, 并且B此时如果要发送数据, 就发送(例如做一些释放前的处理)

再者, B发送完数据之后, 发送FIN给A. (此时B处于半关闭状态)

然后, A发送ACK, 进入TIME-WAIT状态

最后, 经过2MSL时间后没有收到B传来的报文, 则确定B收到了ACK了. (此时A, B才算是处于完全关闭状态)

PS : 仔细分析以上步骤就知道为什么不能少于四次挥手了.

Q : 为什么要等待2MSL(Maximum Segment Lifetime)时间, 才从TIME_WAIT到CLOSED？

A : 在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

更加接地气的解释 :

第一次挥手 : A告诉B, 我没数据发了, 准备关闭连接了, 你要发送数据吗第二次挥手 : B发送最后的数据第三次挥手 : B告诉A, 我也要关闭连接了第四次挥手 : A告诉B你可以关闭了, 我这边也关闭了

应用层

应用层协议最著名的就是HTTP, FTP了, 还有一个重要的DNS

域名系统(DNS, Domain Name System)

DNS 能将域名(例如, www.jianshu.com)解析成IP地址.

域名服务器分类

根域名服务器 : 最高层次的域名服务器
顶级域名服务器 : 如其名
权限域名服务器 : 负责一个区的应服务器
本地域名服务器 : 主机发送DNS查询请求就是发给它

DNS查询

主机向本地域名服务器的查询一般都是采用递归查询
本地域名服务器向根域名服务器的查询通常是采用迭代查询

递归查询 : B问A广州怎么去, A不知道, A就问C, C不知道就问D...直到知道了再一层一层转告直到A告诉B. 迭代查询 : B问A广州怎么去, A不知道, A就告诉你可以去问C, 然后B就去问C, C不知道, C就告诉你可以去问D, 然后B就去问D...直到B知道为止

DNS查询例子 : 域名为x.tom.com的主机想知道y.jerry.com的IP地址

主机x.tom.com先向本地域名服务器dns.tom.com进行递归查询
本地域名服务器采用迭代查询. 它先问一个根域名服务器
根域名服务器告诉它, 你去问顶级域名服务器dns.com
本地域名服务器问顶级域名服务器dns.com
顶级域名服务器告诉它, 你去问权限域名服务器dns.jerry.com
本地域名服务器问权限域名服务器dns.jerry.com
权限域名服务器dns.jerry.com告诉它所查询的主机的IP地址
本地域名服务器把查询结果告诉主机x.tom.com

PS : 该查询使用UDP, 并且为了提高DNS查询效率, 每个域名服务器都使用高速缓存.

URL

URL的格式 : <协议>://<主机>:<端口>/<路径>, 端口和路径有时可省略.

使用HTTP协议的URL : http://<主机>:<端口>/<路径>, HTTP默认端口号是80

HTTP协议

HTTP是面向事务的, 即它传输的数据是一个整体, 要么全部收到, 要么全部收不到.

万维网的工作过程

每一次HTTP请求就需要建立一次TCP连接和释放TCP连接.

HTTP是无连接, 无状态的. 每一次请求都是作为一次新请求.

HTTP/1.0 缺点 : 无连接, 每一次请求都要重新建立TCP连接, 所以每一次HTTP请求都要花费2倍RTT时间(一次TCP请求, 一次HTTP请求)

HTTP/1.1 : 使用持续连接, 即保持TCP连接一段时间.

HTTP/1.1持续工作的两种工作方式 : 非流水线方式和流水线方式非流水线方式 : 收到一个请求的响应再发下一个请求, 效率低, 浪费资源流水线方式 : 能够同时发送多个请求, 效率高

HTTP的GET和POST

GET 请求通常用于查询、获取数据，而 POST 请求则用于发送数据

GET 请求的参数在URL中, 因此绝不能用GET请求传输敏感数据, 而POST 请求的参数在请求头中, 安全性略高于GET请求

ps : POST请求的数据也是以明文的形式存放在请求头中, 因此也不安全

Cookie

万维网使用Cookie来跟踪用户, 表示HTTP服务器和用户之间传递的状态信息.

Cookie工作原理 :

1. 用户浏览某网站, 该网站的服务器为用户产生一个唯一的识别码, 并以此为索引在服务器后端数据库中产生一个项目2. 返回给用户的HTTP响应报文中添加一条 "Set-cookie", 值为该识别码, 如1233. 用户的浏览器将该cookie保存起来, 在用于继续浏览该网站时发送的每一个HTTP请求都会有一行 Cookie: 123于是, 这个网站就知道Cookie为123的这个用户做了什么, 为这个用户维护一个独立的列表(如购物车)

当然, Cookie是把双刃剑, 方便的同时也带有危险性, 例如隐私泄露等, 用户可以自行决定是否使用Cookie

Session

Cookie是保存在客户端上的, 而Session是保存在服务器中. 当服务器收到用户发出的Cookie时, 会根据Cookie中的SessionID来查找对应的Session, 如没有则会生成一个新的SessionID返回给用户

总而言之, Cookie和Session就是同一样东西存放地方不同而已.

HTTPS