网络

计算机网络

TCP/UDP的区别

  1. UDP：用户数据报协议 UDP(User Datagram Protocol)是无连接的，尽最大可能交付，没有拥塞控制，面向报文 (对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部)，支持一对一、一对多、多对一和多对多 的交互通信。

  2. TCP：传输控制协议 TCP(Transmission Control Protocol)是面向连接的，提供可靠交付，有流量控制，拥塞控 制，提供全双工通信，面向字节流(把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据 块)，每一条 TCP 连接只能是点对点的(一对一)。

  3. UDP首部格式

    首部字段只有 8 个字节，包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。

    image-20200602195522814

  4. TCP首部格式

    image-20200602195629503

    1. 序号 :用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。

    2. 确认号 :期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据 长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。

    3. 数据偏移 :指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。

    4. 确认 ACK :当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。

    5. 同步 SYN :在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建 立连接，则响应报文中 SYN=1，ACK=1。

    6. 终止 FIN :用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。

    7. 窗口 :窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空 间是有限的。

TCP如何保证传输的可靠性。

使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。

TCP滑动窗口

  1. 暂时存放字节流。发送方和接收方各有一个窗口，接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其他信息设置自己的窗口大小。

  2. 发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态;接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

  3. 接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前 的所有字节都已经被接收。

    image-20200602202005619

TCP的拥塞控制

  1. 与流量控制的区别：

    1. 流量控制是上一题里窗口，接收方发送窗口值来控制发送方的窗口大小，从而影响发送方的发送速率。将窗口值设置为0，则发送方不能发送数据。
      1. 控制发送方的发送速率，保证接收方来得及接收。

  2. 拥塞控制

    1. 是为了降低整个网络的拥塞程度

    2. 主要通过四个算法进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

    3. 发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量（只是一个状态变量，不是发送方窗口。再区别一下，拥塞窗口讨论的是报文段数量，发送窗口讨论的是字节数量）

    4. 慢开始与拥塞避免

      1. 发送的最初是慢开始，cwnd=1，发送方只能发送一个报文段；接收到确认后，将cwnd加倍，之后能发送的报文段数量是2、4、8..

      2. ssthresh是慢开始门限（初始值自己定），当cwnd >= ssthresh 时，进入拥塞避免，每个轮 次只将 cwnd 加 1。

      3. 如果出现超时，则另ssthresh = cwnd / 2，并重新执行慢开始。

      4. 见图1、2、3

        image-20200602203232342

    5. 快重传与快恢复

      1. 【在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。】

      2. 在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。【例如收到三个 M2，则 M3 丢失，立即重传 M3。】

      3. 同时执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，并直接进入拥塞避免。

      4. 见上图4、5

        image-20200602203554747

TCP建立连接的三次握手

假设A为客户端，B为服务端

  1. 首先B处于监听（listen）状态，等待客户的连接请求
  2. A向B发送连接（SYN，同步）请求报文，SYN=1，ACK=0，seq=x（选择一个初始的序号x）
  3. B收到连接请求报文，如果同意建立连接，则向A发送连接确认报文，SYN=1，ACK=1，ack=x+1（确认号为x+1），seq=y（同时也选择一个初始的序号y）
  4. A收到B的连接确认报文后，还要向B发出确认，seq=x+1（序号为x+1），ack=y+1（确认号为y+1）

为什么要三次握手？

三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

客户端发送的连接请求如果在网络中滞留，那么隔很长时间才能收到服务器发回的连接确认，在这段时间内，客户端等待一个超时重传时间后，就会重新发送连接请求。同时滞留的连接请求最后还是会到达服务器，如果只是两次握手，那么服务器会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

image-20200603103804834

TCP四次挥手断开连接

ack都为1.

  1. A 发送连接释放报文，FIN=1。

  2. B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。

  3. 当 B 不再需要连接时，发送连接释放报文，FIN=1。

  4. A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL(最大报文存活时间)后释放连接。

  5. B 收到 A 的确认后释放连接。

四次挥手的原因

客户端发送FIN连接释放报文后，服务器收到这个报文就进入CLOSE_WAIT状态，这个状态是为了让服务器端发送未传送完毕的数据，发完后服务器就会发送FIN连接释放报文。

TIME_WAIT

客户端收到服务端的FIN报文后进入此状态，并不是直接进入CLOSED状态，还需要等待一个时间计时器设置的时间2MSL。有两个理由：

  1. 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文， A 等待一段时间就是为了处理这种情况的发生。
  2. 等待一段时间是为了让本次连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

image-20200603124530763

哪些典型的应用用的是udp

dns: Domain Name System，域名系统 域名解析

TFTP: Trivial File Transfer Protocol,简单文件传输协议

1.包总量较少的通信（DNS、SNMP等）

2.视频、音频等多媒体通信（即时通信）

3.限定于 LAN 等特定网络中的应用通信

4.广播通信（广播、多播）

HTTP

https和http区别，有没有用过其他安全传输手段？

区别：

  1. http明文传输，安全性低；HTTPS数据加密传输，安全性高
  2. 使用https协议需要到CA（Certificate Authority，数字证书认证机构）申请证书
  3. http的响应速度比HTTPS快，因为HTTPS除了http三次握手的包，还要加上ssl的交互–具体是？
  4. 端口不同，http80端口，https443端口
  5. https本质是构建在ssl/tls之上的http协议

HTTP 与 HTTPS 的区别

Http协议

  1. 基础概念

    1. URI：uniform resource identifier 统一资源标识符

      1. URL：uniform resource locator 统一资源定位符
      2. URN：uniform resource name 统一资源名称
      3. URI包括URL和URN

    2. 请求报文的格式

      1. request line 请求行：请求方法，URL，协议

      2. request headers 请求头：各种header

      3. 请求行和请求头合称为请求消息头

      4. 空行分隔开请求头和请求消息体

      5. request message body 请求消息体：key-value形式或者raw格式等等

        image-20200531143718430

    3. 响应报文的格式

      1. status line 状态行：协议，状态码

      2. response headers 响应头

      3. 状态行和响应头合称为响应消息头

      4. 空行分隔开消息头和消息体

      5. response message body 响应消息体

        image-20200531143732598

  2. HTTP方法

    1. get 主要用来获取资源
    2. head 获取报文首部，主要用于确认 URL 的有效性以及资源更新的日期时间等。
    3. post 主要用来传输数据
    4. put 上传文件，不带验证机制存在安全问题，一般不使用
    5. patch 对资源进行部分修改 – 也不常用
    6. delete 删除文件，与put功能相反，同样不带验证机制
    7. options 查询支持的方法，会返回Allow: GET, POST, HEAD, OPTIONS这样的内容
    8. connect 要求在与代理服务器通信时建立隧道。使用 SSL(Secure Sockets Layer，安全套接层)和 TLS(Transport Layer Security，传输层安全)协议把通信内容 加密后经网络隧道传输。
    9. trace 追踪路径，一般也不用…

  3. HTTP状态码

    简要记一下

    1. 1XX 信息性状态码，接收的请求正在处理
    2. 2XX 请求正常处理完毕
    3. 3XX 重定向
    4. 4XX 客户端错误
    5. 5XX 服务端错误

  4. 再关注下前面的http和HTTPS的比较

其他安全传输手段：SSH

SSH 协议原理、组成、认证方式和过程

延伸

https的特性：加密保证安全性防窃听、认证防伪装、完整性防篡改

加密方式：混合加密，用非对称加密传输对称秘钥，用对称秘钥进行要传输的数据的加解密

认证：使用证书来对通信双方认证。

完整性：ssl提供报文摘要功能来进行完整性保护。

http也可以通过md5验证完整性，但数据篡改后也可重新生成md5，因为是明文的。https是通过ssl的报文摘要来保证完整性的，结合了加密与认证，即使加密后数据被篡改，也很难再生成报文摘要，因为不知道明文是什么。

image-20200411180438085

  1. cookie

    1. 是服务器发送到用户浏览器并保持在本地的一小块数据，会在浏览器向同一服务器再次发起请求时被带上。
    2. 用途：
      1. 会话状态管理（比如用户登录状态、购物车等）
      2. 个性化设置（比如用户自定义设置、主题等）
      3. 浏览器行为分析
    3. 生成方式
      1. 服务器发送Set-Cookie: yummy_cookie=choco这样的header，客户端得到响应报文后把cookie存在浏览器
      2. 浏览器通过document.cookie属性可创建新的cookie
    4. HttpOnly 标记为 HttpOnly 的 Cookie 不能被 JavaScript 脚本调用。
    5. Secure 标记为 Secure 的 Cookie 只能通过被 HTTPS 协议加密过的请求发送给服务端。但即便设置了 Secure 标记，敏感信 息也不应该通过 Cookie 传输，因为 Cookie 有其固有的不安全性，Secure 标记也无法提供确实的安全保障。

  2. session

    1. 存储在服务端，可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中
    2. 使用 Session 维护用户登录状态的过程如下:
      1. 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中;
      2. 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID;
      3. 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中;
      4. 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取 出用户信息，继续之前的业务操作。

  3. cookie和session的选择

    1. cookie只能存储ASCII码字符串，session可以存储任何类型的数据

    2. cookie存储在浏览器中，安全性较低

    3. 对于大型网址，如果所有用户信息都存储在session中，开销比较大 – 【感觉不是个问题…】

session表结构怎么设计，储存在哪里？
  1. 我们项目里没有直接使用session，用的是商城统一单点登录
  3. 如果我设计
    1. 首先一个用户请求过来，如果没有带session id，先重定向到登录页
    2. 收到登录请求，身份验证通过后，生成一个session，key为唯一ID，即session id，value为需要存储的信息，比如用户名、生成时间等，将session id作为cookie响应发回浏览器
    3. 众多的session是key-value结构，session本身也是key-value结构
    4. 存储在Redis
你们的session cookie在项目里运用到哪里？
  1. session是SSO用的，cookie也主要是SSO用的
  2. 偶尔用的cookie是虚拟登录这样的场景
    1. 比如超级账号：员工的erp账号以只读的形式登录到用户账号，主要用于排查问题
    2. 比如账号管家：系统中，账号体系中的主账号可以登录到子账号上，一般也只读
    3. 再如虚拟登录，业务范畴上，两个账号建立授权关系，B账号可以虚拟登录到A账号上，代为操作系统
    4. 实现：被登录人一般是sso中的session对应的用户，属于资源所属者；操作者是erp账号、主账号、虚拟登录账号等，会有登录类型区分，这些信息会先加密，再存入cookie中（还会有不同的拦截器，进行身份和权限验证）
单点登录的实现

  1. CAS

    TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）。【类似session】

    TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。【类似session id】

    ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面的ticket值。

    ps: 未登录状态下，访问app1时，展示登录页，浏览器会写入cas服务器的TGC；第二次访问app2，（因为app2本身校验当前请求未登录）重定向到cas服务器时，会带上TGC，cas服务器根据TGC判断用户已登录，签发新的ST再重定向到app2，这时候app2用ST校验通过，记录下自己的session cookie，提供请求内容。

    img

  2. OAuth 【不看了不看了！】

    https://juejin.im/post/5cc81d5451882524f72cd32c

    https://juejin.im/post/5b3b3b61f265da0f955ca780

    image-20200601201126291

    image-20200601201230467

操作系统

冯诺依曼计算机的结构

运算器（算术逻辑单元，处理寄存器）

控制器（指令寄存器，程序计数器）

存储器（存储数据和指令）

输入设备

输出设备

image-20200613155156585

Linux怎么查看系统负载情况？
  1. uptime
  2. w
  3. top

查看linux系统负载情况

线上服务器cpu飙高，如何处理这个问题
  1. 定位进程：top 查看cpu占用情况
  2. 定位线程：如果是Java应用，top -Hp pid
  3. 定位代码`
    1. printf %x tid 打印出线程ID对应的16进制数 0xtid
    2. jstack pid |grep -A 200 0xtid
内核态 和 用户态、cas 和 sout 哪个用到了内核态和用户态的切换

sout用到了切换

进程的调度
进程间的通讯方式
线程间的同步方式
进程和线程的区别