计算机网络常见面试题

OSI七层模型

​ 应用层，很简单，就是应用程序。这一层负责确定通信对象，并确保由足够的资源用于通信，这些当然都是想要通信的应用程序干的事情。
　　 表示层，负责数据的编码、转化，确保应用层的正常工作。这一层，是将我们看到的界面与二进制间互相转化的地方，就是我们的语言与机器语言间的转化。数据的压缩、解压，加密、解密都发生在这一层。这一层根据不同的应用目的将数据处理为不同的格式，表现出来就是我们看到的各种各样的文件扩展名。
　　 会话层，负责建立、维护、控制会话，区分不同的会话，以及提供单工(Simplex)、半双工(Half duplex)、全双工(Full duplex)三种通信模式的服务。我们平时所知的NFS，RPC,X Windows等都工作在这一层。

传输层，负责分割、组合数据，实现端到端的逻辑连接。数据在上三层是整体的，到了这一层开始被分割，这一层分割后的数据被称为段(Segment)。三次握手(Three-way handshake)，面向连接(Connection-Oriented)或非面向连接(Connectionless-Oriented)的服务，流控(Flow control)等都发生在这一层。
　　 网络层，负责管理网络地址，定位设备，决定路由。我们所熟知的IP地址和路由器就是工作在这一层。上层的数据段在这一层被分割，封装后叫做包(Packet)，包有两种，一种叫做用户数据包(Data packets)，是上层传下来的用户数据；另一种叫路由更新包(Route update packets)，是直接由路由器发出来的，用来和其他路由器进行路由信息的交换。
　　 数据链路层，负责准备物理传输，CRC校验，错误通知，网络拓扑，流控等。我们所熟知的MAC地址和交换机都工作在这一层。上层传下来的包在这一层被分割封装后叫做帧(Frame)。
　　 物理层，就是实实在在的物理链路，负责将数据以比特流的方式发送、接收。

为什么要分层

点击url发生了什么

总体来说分为以下几个过程:

1. DNS解析
2. TCP连接
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

HTTPS和HTTP的区别

HTTP报文是包裹在TCP报文中发送的，服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中存在一定的风险，HTTP报文是明文，如果中间被截取的话会存在一些信息泄露的风险。那么在进入TCP报文之前对HTTP做一次加密就可以解决这个问题了。HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。

HTTPS过程

1. tcp三次握手
2. SSL四次握手

•   1. 客户端向服务器所要证书
  

•   2. 服务器发送证书
  

•   3. 客户端验证证书，提取公钥，发送用此公钥加密的对称密钥。
  

•   4. 服务端收到密钥，响应OK
  

参考

HTTPS在传输数据之前需要客户端与服务器进行一个握手(TLS/SSL握手)，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL使用了非对称加密，对称加密以及hash等。具体过程请参考经典的阮一峰先生的博客TLS/SSL握手过程。
HTTPS相比于HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用HTTPS需要根据具体情况在安全和性能方面做出权衡。

1. 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

2. 安全性和资源消耗：

   HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

   • 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
   • 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

数字签名

而数字签名，它的作用跟手写签名其实是一样的，用来证明某个消息或者文件是本人发出/认同的。有不可伪造和不可抵赖两个特性。

hash算法：是单向加密。就是只能从明文得到密文，却无法从密文得到明文。这种算法有一个好处，就是明文哪怕只有一位不一样，加密后得到的密文也不一样。所以常用来进行比较明文是否被篡改过。

HTTPS数字证书

三次握手

简易示意图：

• 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
• 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
• 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端

为什么要三次握手

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

假如没有三次握手，可能会出现什么情况

反例：A发出连接请求，但因为丢失了，故而不能收到B的确认。于是A重新发出请求。

​ 但是，某种情况下，A的第一个连接请求在某个节点滞留了，延误到达。在A已经发送第二个连接请求，并且得到B的回应，建立了连接以后，这个报文段竟然到达了（本来这是一个早已失效的报文段），于是B就认为，A又发送了一个新的请求，于是发送确认报文段，同意建立连接，假若没有三次的握手，那么这个连接就建立起来了（有一个请求和一个回应），此时，A收到B的确认，但A知道自己并没有发送建立连接的请求，因为不会理睬B的这个确认，于是呢，A也不会发送任何数据，而B呢却以为新的连接建立了起来，一直等待A发送数据给自己，此时B的资源就被白白浪费了。但是采用三次握手的话，A就不发送确认，那么B由于收不到确认，也就知道并没有要求建立连接。

第2次握手传回了ACK，为什么还要传回SYN？

接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。”

DoS, DDoS, SYN泛洪攻击

A（攻击者）发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当这个服务器返回ACK以后，A不再进行确认，那这个连接就处在了一个挂起的状态，也就是半连接的意思，那么服务器收不到再确认的一个消息，还会重复发送ACK给A。这样一来就会更加浪费服务器的资源。A就对服务器发送非法大量的这种TCP连接，由于每一个都没法完成握手的机制，所以它就会消耗服务器的内存最后可能导致服务器死机，就无法正常工作了。更进一步说，如果这些半连接的握手请求是恶意程序发出，并且持续不断，那么就会导致服务端较长时间内丧失服务功能——这样就形成了DoS攻击。这种攻击方式就称为SYN泛洪攻击。

如何防范：

最常用的一个手段就是优化主机系统设置。比如降低SYN timeout时间，使得主机尽快释放半连接的占用或者采用SYN cookie设置，如果短时间内收到了某个IP的重复SYN请求，我们就认为受到了攻击。我们合理的采用防火墙设置等外部网络也可以进行拦截。

四次挥手

断开一个 TCP 连接则需要“四次挥手”：

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
• 服务器-关闭与客户端的连接，发送一个FIN给客户端
• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

CLOSE_WAIT: 被动关闭方收到FIN, 发送ack后进入CLOSE_WAIT

TIME_WAIT: TIME_WAIT 是主动关闭链接时形成的，等待2MSL时间，约4分钟。主要是防止最后一个ACK丢失。 由于TIME_WAIT 的时间会非常长，因此server端应尽量减少主动关闭连接

**等待2MSL的原因：**为了保证客户端最后一次挥手的报文能够到达服务器，若第4次挥手的报文段丢失了，服务器就会超时重传第3次挥手的报文段，所以客户端此时不是直接进入CLOSED，而是保持TIME_WAIT（等待2MSL就是TIME_WAIT）。当客户端再次受到服务器因为超时重传而发送的第3次挥手的请求时，客户端就会重新给服务器发送第4次挥手的报文（保证服务器能够受到客户端的回应报文）

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

TCP第四次挥手为什么要等待2MSL

1、为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

2、他还可以防止已失效的报文段。客户端在发送最后一个ACK之后，再经过经过2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器。

服务器出现大量TIME_WAIT状态怎么解决

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_tw_reuse启用时，当主动关闭连接的一方，再次向对方发起连接请求的时候，可以复用TIME_WAIT状态的连接。 系统根据时间戳判断是否是延迟的数据，如果是，则丢弃。
net.ipv4.tcp_tw_recycle启用时，回收时间不再是2msl而是一个RTO（retransmission timeout，数据包重传的timeout时间），远小于2msl，约0.7s。
客户端：短连接改长连接
HTTP 请求的头部， connection 设置为 keep-alive， 保持存活一段时间；

长连接从根本上减少了关闭连接的次数，减少了TIME_WAIT状态的产生数量，在高并发的系统中非常有效，现在的浏览器， 一般都这么进行了 。

TCP和UDP协议的区别

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

为什么说UDP是面向报文的，而TCP是面向字节流的？

发送方的UDP 对应用程序交下来的报文，在添加首部后就向下交付IP 层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给UDP 多长的报文， UDP 就照样发送，即一次发送一个报文。

在接收方的UDP, 对IP 层交上来的UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程。也就是说， UDP 一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长， UDP 把它交给IP 层后， IP 层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短， UDP 把它交给IP 层后，会使IP 数据报的首部的相对长度太大，这也降低了IP 层的效率。

TCP通过字节流传输，即TCP将应用程序看成是一连串的无结构的字节流。每个TCP套接口有一个发送缓冲区，如果字节流太长时，TCP会将其拆分进行发送,当字节流太短时，TCP会等待缓冲区中的字节流达到一定程度时再构成报文发送出去

ARQ协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议

• 停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；
• 在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；

优点： 简单

缺点： 信道利用率低，等待时间长

连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

如何保证有序

1. 主机每次发送数据时，TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收主机对分配的这个序列号进行确认，

2. 如果发送主机在一个特定时间内没有收到接收主机的确认，则发送主机会重传此数据包。

3. 接收主机利用序列号对接收的数据进行确认，以便检测对方发送的数据是否有丢失或者乱序等

4. 接收主机一旦收到已经顺序化的数据，它就将这些数据按正确的顺序重组成数据流并传递到高层进行处理

拥塞控制

拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

慢开始：当拥塞窗口cwnd<慢开始门限ssthresh时，采用慢开始算法，每经过一个传输轮次，拥塞窗口cwnd就加倍。用这样的方法逐步增大发送方的拥塞窗口cwnd,可以使分组注入到网络的速率更加合理。

拥塞避免：为了防止拥塞窗口cwnd增长过大引起网络拥塞，当cwnd>ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。即每经过一个往返时间RTT,就把发送方的拥塞窗口cwnd加1,而不是加倍。这样，拥塞窗口cwnd按线性规律缓慢增长（加法增大）

快重传：快重传算法首先要求接收方每收到一个失序的报文段后，就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方），而不要等待自已发送数据时才进行捎带确认。发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。

快恢复：当发送端收到连续三个重复的确认时，执行快恢复算法。ssthresh=cwnd/2, cwnd = ssthresh, 执行拥塞避免算法。(乘法减小)

常见面试题

1.传输层协议有哪些，常见的应用层协议有哪些?

传输层协议：UDP, TCP

应用层：HTTP, HTTPS, SMTP, FTP,DNS

2.HTTP GET和POST有什么不同?

• GET 用于获取信息，是无副作用的，是幂等的，且可缓存。数据在URL中对全部人可见。
• POST 用于修改服务器上的数据，有副作用，非幂等，不可缓存。数据不显示在URL中。比get更安全。

3.什么是子网掩码？

子网掩码，它是一种用来指明一个IP地址的哪些位标识的是主机所在的子网，以及哪些位标识的是主机的位掩码。子网掩码不能单独存在，它必须结合IP地址一起使用。子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。

4.HTTP状态码

1XX: 信息状态码

2XX: 成功状态码

3XX: 重定向状态码

4XX: 客户端错误状态码

5XX: 服务端错误状态码

5.Http是长连接的

1. HTTP协议与TCP/IP协议的关系

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。

2. 如何理解HTTP协议是无状态的

HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和上一次打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

3. 什么是长连接、短连接？

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

TCP短连接

模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。

短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。

TCP长连接

我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

TCP的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：

• 客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。
• 客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。
• 客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
• 客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

长连接和短连接的优点和缺点

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

6.udp是否可以实现可靠传输

可以。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。实现确认机制、重传机制、窗口确认机制。

7.TCP沾包现象

https://blog.csdn.net/DamonREN/article/details/88119294

8.Session，cookie和token的区别？

http是一个无状态协议

什么是无状态呢？就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。这种无状态的的好处是快速。坏处是假如我们想要把www.zhihu.com/login.html和www.zhihu.com/index.html关联起来，必须使用某些手段和工具

cookie和session

由于http的无状态性，为了使某个域名下的所有网页能够共享某些数据，session和cookie出现了。客户端访问服务器的流程如下

• 首先，客户端会发送一个http请求到服务器端。
• 服务器端接受客户端请求后，建立一个session，并发送一个http响应到客户端，这个响应头，其中就包含Set-Cookie头部。该头部包含了sessionId。Set-Cookie格式如下，具体请看Cookie详解
  Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
• 在客户端发起的第二次请求，假如服务器给了set-Cookie，浏览器会自动在请求头中添加cookie
• 服务器接收请求，分解cookie，验证信息，核对成功后返回response给客户端

注意

• cookie只是实现session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在url中
• 现在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用
• 用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。如果全部用cookie，数据量大的时候客户端是没有那么多空间的。
• 如果只用cookie不用session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大

小结

简而言之, session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 cookie 就是用户通行证

token

token 也称作令牌，由uid+time+sign[+固定参数]
token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据。

组成

• uid: 用户唯一身份标识
• time: 当前时间的时间戳
• sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
• 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

存放

token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般存于数据库中

token认证流程

token 的认证流程与cookie很相似

• 用户登录，成功后服务器返回Token给客户端。
• 客户端收到数据后保存在客户端
• 客户端再次访问服务器，将token放入headers中
• 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

总结

• session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie
• cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。
• token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。

网络编程

Socket编程

Socket 是对 TCP/IP 协议族的一种封装，是应用层与TCP/IP协议族通信的中间软件抽象层。从设计模式的角度看来，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

Socket 还可以认为是一种网络间不同计算机上的进程通信的一种方法，利用三元组（ip地址，协议，端口）就可以唯一标识网络中的进程，网络中的进程通信可以利用这个标志与其它进程进行交互。

Socket 起源于 Unix ，Unix/Linux 基本哲学之一就是“一切皆文件”，都可以用“打开(open) –> 读写(write/read) –> 关闭(close)”模式来进行操作。因此 Socket 也被处理为一种特殊的文件。

Socket类型

创建 socket 的时候需要指定 socket 的类型，一般有三种：

• SOCK_STREAM：面向连接的稳定通信，底层是 TCP 协议，我们会一直使用这个。
• SOCK_DGRAM：无连接的通信，底层是 UDP 协议，需要上层的协议来保证可靠性。
• SOCK_RAW：更加灵活的数据控制，能让你指定 IP 头部

Socket编程接口

• socket()：创建socket
• bind()：绑定socket到本地地址和端口，通常由服务端调用
• listen()：TCP专用，开启监听模式
• accept()：TCP专用，服务器等待客户端连接，一般是阻塞态
• connect()：TCP专用，客户端主动连接服务器
• send()：TCP专用，发送数据
• recv()：TCP专用，接收数据
• sendto()：UDP专用，发送数据到指定的IP地址和端口
• recvfrom()：UDP专用，接收数据，返回数据远端的IP地址和端口
• closesocket()：关闭socket

基于TCP/IP的通信基本上都是利用SOCKET套接字进行数据通讯，程序一般分为服务器端和用户端两部分。设计思路（visual studio下）：
第一部分　服务器端
　　一、创建服务器套接字（create）。
　　二、服务器套接字进行信息绑定（bind），并开始监听连接（listen）。
　　三、接受来自用户端的连接请求（accept）。
　　四、开始数据传输(send/receive)。
　　五、关闭套接字（closesocket）。

第二部分　客户端
　　一、创建客户套接字（create）。
　　二、与远程服务器进行连接（connect），如被接受则创建接收进程。
　　三、开始数据传输(send/receive)。
　　四、关闭套接字（closesocket）。

#include<stdio.h>
#include<stdlib.h>
#include<WinSock2.h>  //WindowsSocket编程头文件
#include<iostream>
#include<cstring>
#pragma comment(lib,"ws2_32.lib")//链接ws2_32.lib库文件到此项目中
using namespace std;

//================全局常量==================
       //创建缓冲区
const int BUF_SIZE = 2048;
//================全局变量==================
SOCKET sockSer, sockCli;
SOCKADDR_IN addrSer, addrCli; //address
int naddr = sizeof(SOCKADDR_IN);

char sendbuf[BUF_SIZE];
char inputbuf[BUF_SIZE];
char recvbuf[BUF_SIZE];
//================函数声明==================
int main() {
  cout << "服务器启动" << endl;
  //加载socket库
  WSADATA wsadata;
  if (WSAStartup(MAKEWORD(2, 2),&wsadata) != 0)
  {
  	//输出出错信息
  	cout << "载入socket库失败!" << endl;
  	system("pause");
  	return 0;
  }
  else {
  	cout << "载入socket库成功!" << endl;
  }
  //创建Soucket;
  sockSer = socket(AF_INET, SOCK_STREAM, 0);
  //描述协议族,INET属于ipv4；
  //sock_stream创建套接字类型：tcp；
  //0不指定协议，常用的协议有tcp、udp等

  //初始化地址包
  addrSer.sin_addr.s_addr = inet_addr("192.168.138.1");
  addrSer.sin_family = AF_INET;
  addrSer.sin_port = htons(1111);

  //绑定Socket(bind)
  bind(sockSer, (SOCKADDR*)&addrSer, sizeof(SOCKADDR));
  //强制将SOCKADDR_INET转化成SOCKEADDR

  //监听
  while (true) {
  	cout << "开始连接!" << endl;
  	//监听连接请求;
  	listen(sockSer,5);
  	//等待连接最大数：5

  	//接受连接
  	sockCli=accept(sockSer, (SOCKADDR*)&addrCli, &naddr);
  	if (sockCli != INVALID_SOCKET) {
  		while (true)
  		{
  			cout << "连接成功" << endl;
  			cout << "请输入要发送给客户端的信息：" << endl;
  			cin >> sendbuf;
  			send(sockCli, sendbuf, sizeof(sendbuf), 0);
  			//strcpy(sendbuf, "hello");
  			//send(sockCli, sendbuf, sizeof(sendbuf), 0);

  			//接收客户端发来信息
  			recv(sockCli, recvbuf, sizeof(recvbuf), 0);
  			cout << "客户端发来的信息：" << recvbuf << endl;
  		}
  		
  	}
  	else
  	{
  		cout << "连接失败!" << endl;
  	}
  }
  closesocket(sockSer);
  closesocket(sockCli);
  return 0;

}

client:

#include<stdio.h>
#include<stdlib.h>
#include<WinSock2.h>  //WindowsSocket编程头文件
#include<iostream>
#include<cstring>
#pragma comment(lib,"ws2_32.lib")//链接ws2_32.lib库文件到此项目中
using namespace std;
 
//================全局常量==================
//创建缓冲区
const int BUF_SIZE = 2048;
//================全局变量==================
SOCKET sockSer, sockCli;
SOCKADDR_IN addrSer, addrCli; //address
int naddr = sizeof(SOCKADDR_IN);
 
char sendbuf[BUF_SIZE];
char inputbuf[BUF_SIZE];
char recvbuf[BUF_SIZE];
//================函数声明==================
int main() {
	//加载socket库
	cout << "客户端启动" << endl;
	WSADATA wsadata;
	if (WSAStartup(MAKEWORD(2, 2), &wsadata) != 0)
	{
		//输出出错信息
		cout << "载入socket库" << endl;
		system("pause");
		return 0;
	}
	//创建Soucket;
	sockCli = socket(AF_INET, SOCK_STREAM, 0);
	//描述协议族,INET属于ipv4；
	//sock_stream创建套接字类型：tcp；
	//0不指定协议，常用的协议有tcp、udp等
 
	//初始化客户端地址包
	addrCli.sin_addr.s_addr = inet_addr("127.0.0.1");
	addrCli.sin_family = AF_INET;
	addrCli.sin_port = htons(1111);
 
	//初始化服务器地址
	addrSer.sin_addr.s_addr = inet_addr("192.168.138.1");
	addrSer.sin_family = AF_INET;
	addrSer.sin_port = htons(1111);
 
	while (true)
	{
		if (connect(sockCli, (SOCKADDR*)&addrSer, sizeof(addrSer))!=SOCKET_ERROR)
		{
			while (true)
			{
				//接收服务器信息
				cout << "客户端连接成功" << endl;
				recv(sockCli, recvbuf, sizeof(recvbuf), 0);
				cout << "服务端发的信息：" << recvbuf << endl;
				//发送给服务器信息
				cout << "请输入要发送给服务器的信息：" << endl;
				cin >> sendbuf;
 
				send(sockCli, sendbuf, sizeof(sendbuf), 0);
				cout << "发送成功" << endl;
			}
			
		}
		else
		{
			//cout << "客户端连接失败" << endl;
		}
	}
	closesocket(sockSer);
	closesocket(sockCli);
	return 0;
}