Computer Network.
五层模型 个体单位 协议 作用 设备
物理层 比特/比特流 / 定义物理传输设备标准 网卡
数据链路层 帧 / 定义如何格式化数据，提供错误检测 交换机
网络层 数据包 IP 将网络地址翻译成物理地址 路由器
传输层 数据段 TCP/UDP 解决主机间的数据传输与传输质量(最重要) 进程和端口
应用层 报文 DNS/FTP/HTTP 文件传输，电子邮件 /

三次握手

TCP Flags

URG:紧急指针标志(1表示紧急指针有效 0表示忽略紧急指针)

ACK:确认序号标志(1表示有效 0表示报文中不包含确认信息 忽略确认号字段)

PSH:push标志(1表示带有push数据应尽快将该报文交给应用程序)

RST:重置连接标志(重置由于主机崩溃的错误连接 或 用于拒绝非法报文段或非法请求)

SYN:同步序列号(建立连接过程 SYN=1 ACK=0表示该数据没有使用捎带的确认域 连接应答捎带的SYN=ACK=1)

FIN:finish标志，用于释放连接 唯一时表示发送方没有数据发送了 可以关闭本方数据流

Procedure

三次握手

  1. 首次通信 客户端主动打开连接 服务端被动打开连接 服务进程创建传输控制块TCB 准备接受客户进程发送的请求 服务端进入listen状态 客户端发送syn=1即等待建立连接 同时发送一个SYN包(seq=x) 并进入SYN-SENT状态 该报文段成为syn报文段 不存储数据 需要消耗一个序号

  2. 服务端接收到请求报文后 则发出确认报文(SYN=1 ACK=1) 同时确认客户的SYN(ack=x+1) 自己也发送一个SYN包(seq=y) 即SYN+ACK包 此时服务器进入SYN-RECV状态

  3. 客户端还要给服务端一个确认报文 回应的ack=y+1 seq初始为x 那这个就是x+1了 可携带也可不携带数据 这样客户端和服务器端一起进入ESTABLISHED状态 完成三次握手

    现在TCP连接建立。

For what

  1. 为了初始化Sequence Number的初始值(x和y) 保证不会因为网络问题乱序 因此需要三次握手才建立连接
  2. 首次握手的隐患的隐患：
    • server收到client的SYN 回复SYN-ACK的时候未收到ACK确认(第三次握手gg了)
    • server不断重试直至超时 linux默认等待63秒才断开连接(1+2+4+8+16+32)(linux默认五次)
    • 针对SYN Flood的防护措施
      • SYN队列满后 通过tcp_syncookies参数回发SYN Cookie
      • 若为正常连接则client会回发SYN Cookie 直接建立连接
  3. 已经建立连接后client出现故障：
    • 向对方发送保活探测报文 如果未收到响应则继续发送
    • 尝试次数达到保活探测数仍未受到相应则中断连接

保活机制

四次握手

Procedure

四次挥手

  1. client发送一个FIN 用来关闭client到server的数据传送 client进入FIN_WAIT_1状态

  2. server收到FIN后 发送一个ACK给client 确认序号为收到序号+1(与SYN相同 一个FIN占用一个序号) server进入CLOSE_WAIT半关闭状态

  3. server发送一个FIN 用来关闭server到client的数据传送 server进入LAST_ACK状态

  4. client收到FIN后client进入TIME_WAIT状态 接着发送一个ACK给server 确认序号为收到序号+1 server进入closed状态 完成四次挥手

    现在TCP连接终止。

For what

  1. 为何会有TIME_WAIT状态
    • 确保有足够时间让对方收到ACK包(第四次挥手)
    • 避免新旧连接混淆(路由器缓存)
  2. 为何需要四次握手才能断开
    • TCP全双工 发送方和接收方都需要FIN报文和ACK报文
    • 各只需要两次握手即可 不过有一方是被动的
  3. 服务器出现大量CLOSE_WAIT状态原因
    • 对方关闭socket连接 我方忙于读或写 没有及时关闭连接
      • 检查代码 特别是释放资源的代码
      • 检查配置 特别是处理请求的线程配置

TCP/UDP区别

UDP

  • 面向非连接
  • 不维护连接状态 支持同时向多个客户端传输相同的消息
  • 数据包报头只有8个字节 额外开销较小
  • 吞吐量只受限于数据生成速率 传输生成速率以及机器性能
  • 尽最大努力交付 不保证可靠交付 不需要维持复杂的链接状态表
  • 面向报文 不对应用程序提交的报文信息进行拆分或者合并

Difference

  • 面向连接 vs 无连接
  • 可靠性
  • 有序性
  • 速度(TCP较慢 需要做可靠性检测)
  • 量级(TCP20个字节 UDP8个字节)

TCP的滑窗

TCP/IP详解：卷一 协议

RTT和RTO

  • RTT：发送一个数据包到收到对应的ACK 所花费的时间
  • RTO：重传的时间间隔

Sliding Window

  • 保证TCP的可靠性
  • 保证TCP的流控特性

HTTP相关

特点

  • 支持客户/服务器模式
  • 简单快速(规模小)
  • 灵活(允许传输任意类型数据对象)
  • 无连接(限制每次连接只处理一个请求)

请求/相应步骤

  • 客户端连接到WEB服务器
  • 发送HTTP请求
  • 服务器接收请求并返回HTTP相应
  • 释放连接tcp链接
  • 客户端浏览器解析html内容

浏览器输入URL后流程

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

HTTP状态码

  • 1xx：指示信息 表示请求已接收 继续处理
  • 2xx：成功 表示请求已被成功接收 理解 接收
    • 200 OK 整成返回信息
  • 3xx：重定向 要完成请求必须进行更进一步的操作
  • 4xx：客户端错误 请求有语法错误或请求无法实现
    • 400 Bad Request 客户端请求有语法错误 不能被服务器所理解
    • 403 Forbidden 服务器收到请求但是拒绝提供服务
    • 404 Not Found 请求资源不存在 eg. 输入了错误的URL
  • 5xx：服务器端错误 服务器未能实现合法的请求
    • 500 Internal Server Error 服务期发生不可预期的错误
    • 503 Server Unavailable 服务器当前不能处理客户端的请求 一段时间后可能恢复正常

Get和Post请求的区别

  • http报文层面：get将请求信息放在url post放在报文体中
  • 数据库层面：get符合幂等性(数据库一次操作 多次操作结果一样)和安全性 post不符合
  • 其他：get可以被缓存被存储 而post不行

Cookie和Session的区别

Cookie简介

  • 是由服务器发给客户端的特殊信息 以文本的形式存放在客户端
  • 客户端再次请求的时候会把cookie回发
  • 服务器接收到后 会解析cookie生成与客户端相对应的内容

Session简介

  • 服务器端的机制 在服务器上保存的信息
  • 解析客户端请求并操作session id 按需保存状态信息

Session实现方式

  • 使用cookie来实现 服务器给每个session分配一个jsessionid
  • 使用url回写来实现

Difference

  • cookie数据存放在客户的浏览器上 session数据存放在服务器上
  • session相对于cookie更安全
  • 若考虑减轻服务器负担 应当使用cookie

Http与Https的区别

SSL(Security Socket Layer)

  • 为网络通信提供安全及数据完整性的一种安全协议
  • 是操作系统对外的API SSL3.0后更名为TLS
  • 采用身份验证和数据加密保证网络通信的安全和数据的完整性

加密方式

  • 对称加密：加密解密都是用同一个密钥
  • 非对称加密：加密使用的密钥和解密使用的密钥是不相同的
  • 哈希算法：将任意长度的信息转换为固定长度的值 算法不可逆
  • 数字签名：证明某个消息或者文件时某人发出/认同的

Https数据传输流程

  1. 浏览器将支持的加密算法信息发送给服务器
  2. 服务器选择一套浏览器支持的加密算法 以证书的形式回发浏览器
  3. 浏览器验证证书合法性 并结合证书公钥加密信息发送给服务器
  4. 服务器使用私钥解密信息 验证哈希 加密相应消息回发给浏览器
  5. 浏览器解密响应消息 并对消息进行验证 之后进行加密交互数据

Difference

  • https需要到CA申请证书 http不需要
  • 前者密文传输 后者明文传输
  • 连接方式不同 端口不同
  • https = http + 加密 + 认证 + 完整性保护 较http安全

Socket相关

socket通信流程