计算机网络

浏览器URL回车后发生了什么

用户输入
浏览器处理——DNS解析，解析出IP
向服务器发送请求，服务器接收并处理，返回响应——HTTP/HTTPS && CA && TLS

浏览器处理——引擎处理，渲染结果（若有

以主HTML文件为入口，进行依赖解析并导入相关脚本，meta=>DOM && script

用户接收

如何对其优化？

核心逻辑
	针对请求资源文件进行处理，而不是不可控的部分
网络方面
	- 资源动态导入，包括JS、CSS、Assets
	- 切换库：CDN
	- 对资源加载方式处理——延迟资源加载：
		- 对已有的资源：通过defer && async
		- 对未有的资源：通过SSR
数据方面
	- 减少打包体积 / 代码压缩

三次握手与四次挥手

三次握手为什么是三次，不是两次或四次？

三次握手本质上是以最少的次数确定对方是否有与自身通讯的能力
    client：SYN
    server：ACK SYN
    client：ACK

如果为两次：响应时间是不确定的，一方可能会无限等待
如果为四次：则额外做了不必要的检查，三次就足以检查双方的通信能力

四次挥手为什么是四次，三次不行吗，五次呢？

·报文段1：
	A FIN。
	主动关闭方向被动关闭方发送结束报文段。
·报文段2：
	B ACK
	被动关闭方发送结束报文段确认，此时主动关闭方数据已经传输完毕。
·报文段3：
	B FIN ACK
	被动关闭方数据也发送完毕，发送结束报文段。
·报文段4：
	A ACK
	closed
	主动关闭方对结束报文段进行确认。

ACK用来应答，SYN用来同步
如果为三次：则不等待server端资源处理完毕就终止链接，一方面浪费了服务端资源，另一方面容易造成服务端在下次连接时因为资源占用而无法连接
如果为五次：没有必要，四次的通信已经确认了服务端资源处理完毕

（关键在于第二段挥手。Server段只发送ACK，意思是我收到了结束请求。而服务端是可以一下子发送FIN和ACK的，但是第二段挥手没有一次性发完是因为，我现在身上还有活，等我忙完了我再发FIN和ACK。类比聚餐，朋友打来电话要你现在来，而自己还有些活没忙完，这时候你会说“等我忙完了再过去”是一个道理。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。）

HTTP基础

http请求的方法，说说put，这样做为了什么规范
https和http ？讲了混合加密过程和ssl证书数字签名等等。

http

特点

是否加密：明文传输，数据不加密
响应速度：快（三次握手）
性能开销：低
端口：80

请求

GET 检索资源
POST 创建新资源，需要一个request body并填入headers
PUT 修改资源 PUT会修改替换整个资源，若无匹配则生成新的资源
- PUT和POST的区别：
  PUT操作幂等，POST则不是
- PUT和PATCH的区别：
  PUT找不到资源时会创建新资源；PATCH不会
  PUT想修改一个字段都需要填满所有数据；PATCH填什么修改什么
PATCH 修改资源 PATCH只会修改部分资源字段
DELETE 删除资源

https

建立在SSL/TLS之上的HTTP协议

特点

是否加密：密文传输，数据加密
响应速度：慢（三次握手+SSL握手共12个包）
性能开销：高
端口：443

流程

client request
服务端传送公钥（服务器需要有数字证书（公钥+私钥），可以自己制作也可以向组织申请）
客户端解析（通过TLS完成，检验是否有效）
客户端传送加密信息（通过证书加密的随机值，以后的通信使用该值）
服务端解析（通过私钥解密获取随机值，再将信息通过对称加密（私钥+随机值+算法））
服务端传送加密信息（可在客户端还原）
客户端解密信息（使用之前生成的私钥解密服务端传递的信息，即便第三方监听到数据也没用）

SSL/TLS

SSL(Secure Socket Layer，安全套接层) & TLS(Transport Layer Security，传输层安全，实际上是SSL的3.0版本)是一种密码通信框架

1. 客户端发送请求

客户端（通常是浏览器）请求与服务器建立安全连接。

2. 服务器响应

服务器返回包含 SSL 证书的响应。SSL 证书包含服务器的公钥以及其他身份验证信息。

3. 客户端验证证书

客户端验证服务器的 SSL 证书是否由受信任的证书颁发机构（CA）签发。如果验证通过，客户端生成一个称为“会话密钥”的对称密钥。

4. 客户端加密会话密钥

客户端使用服务器的公钥加密会话密钥，然后将加密的会话密钥发送给服务器。

5. 服务器解密会话密钥

服务器使用自己的私钥解密会话密钥。此时，客户端和服务器都拥有了相同的会话密钥。

6. 使用会话密钥进行加密通信

后续通信使用对称加密，使用会话密钥来加密和解密传输的数据。这种方式比非对称加密更高效。

webHooks 与 webSockets

Webhooks

协议：使用 HTTP 协议
特点：由服务器向客户端发起请求，俗称反向API，客户端不需要保持持续的连接状态
适用于：不频繁但重要的事件通知，如服务集成、自动化流程触发、数据同步等
通信方式：单向通信，从服务器到客户端。
资源消耗：低

WebSocket

协议： WebSocket 协议（ws 或 wss）
前置条件：需要先进行HTTP握手，之后就升级为WebSocket连接
特点：双方可以在任意时刻发送数据，无需等待对方的响应
适用于：实时通信和低延迟
通信方式：全双工通信
资源消耗：高

HTTP缓存

了解浏览器的缓存策略吗？

缓存本身是计算机的内存，同时开辟硬盘作为数据存储区域，通过这块区域来缓存信息

HTTP缓存=浏览器缓存+服务器缓存

前端缓存

Cookie，localStorage，SessionSotrage，IndexedDB

Cookie：4KB、每次请求都会加在请求头里、非敏感信息、浏览器关闭消失、同源限制
只有在同一域名和路径下的网站才能共享Cookie信息
localStorage：5MB、永久、同步、同源限制
SessionSotage：5MB、会话、同步、同源限制
IndexedDB：5-50MB、对象存储、异步请求、同源限制、并发限制

后端缓存

方式：HTTP主要通过请求和相应Header来控制缓存，缩短网络请求距离

优点：

节省流量
降低网络负荷
提高响应速度

分类(是否需要重新向服务器发送请求)

强缓存 (直接读取缓存，返回200)
由header中的Pragma、Cache-Control、Expires控制
协商缓存 (重新发送请求，返回304)
由header中的Etag和LastModified控制

*用户行为

新页面、前进、后退: 均有效
F5: 仅对协商缓存有效
ctrl+f5:均无效

什么是缓存雪崩？导致雪崩的原因是什么？

雪太多（最终到数据库的请求过多，导致数据库无法访问

问题

同一url的两个页面会共享localStorage和sessionStorage吗？ local共享、session不共享

如何设置禁用缓存？

服务端:
	设置Nginx && Apache的header——Cache-Control
客户端:
	浏览器 && devtool禁用
	meta标签设置禁用
		<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
		<meta http-equiv="Pragma" content="no-cache" />
		<meta http-equiv="Expires" content="0" />

跨域

跨域问题有遇到过吗？怎么解决的呢？实际项目和实习中遇到是怎么解决的？

跨域可以设置前端的跨域，也可以设置后端的跨域；后端更重要；

	JSONP 动态创建script标签
	CORS 服务端设置请求头
	websocket
	代理服务器

同源的定义

协议、端口号、域名完全相同

跨域方式

CORS
CORS是跨域的实现方式之一，比JSONP更强大。
JSONP
JSONP只支持GET请求，CORS支持所有类型的HTTP请求
JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。
Node中间件代理 && Nginx反向代理
基于iframe的代理

CORS

CORS正常的请求和相应

http

PUT /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

HTTP

// 访问控制允许域
Access-Control-Allow-Origin: http://api.bob.com 
Content-Type: text/html; charset=utf-8

发送Cookie到服务器

CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：
Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。

后端：设置Access-Control-Allow-Credentials: true
前端：
    var xhr = new XMLHttpRequest();
    xhr.withCredentials = true;

* 如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。

CORS请求类别

AJAX 的跨域设计就是，只要表单可以发，AJAX 就可以直接发。

简单请求

必要条件：
    方法限制在GET、POST、HEAD
    HTTP头限制在五个，其中Content-Type只限于三个值
        application/x-www-form-urlencoded
        multipart/form-data
        text/plain

Request：
	对HTTP头增加Origin字段，后端得以判断

Response：
    不在可允许范围内，返回正常HTTP请求；
    在可允许范围内， 会返回额外添加的头部信息：
        Content-Type: text/html; charset=utf-8
        Access-Control-Allow-Origin: http://api.bob.com  //必填 要么是原值，要么是*
        Access-Control-Allow-Credentials: true  		 //默认情况下，Cookie不包括在CORS请求之中；设置为ture则允许客户端发送Cookie到服务器
        Access-Control-Expose-Headers: FooBar			 //获取指定的请求头

预检请求

在正式通信之前，增加一次HTTP查询请求；

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。

必要条件：
	方法为PUT或DELETE，或者Content-Type字段的类型是application/json。

Request：
	HTTP头中, 除Origin外, 增加两个特殊字段：
		Access-Control-Request-Method						// 必填，为HTTP方法
		Access-Control-Request-Headers						// 浏览器CORS请求会额外发送的头信息字段

Response：
	检查发送的三个字段
	若成功，则增加额外的HTTP头：
		Access-Control-Allow-Origin: *					// 同上，value为原值或*
        Access-Control-Allow-Methods: GET, POST, PUT	// 必填，value为允许通过的方法
        Access-Control-Allow-Headers: ...				// 若前端设置了额外的头部信息Access-Control-Request-Headers, 则该字段必填
        Access-Control-Allow-Credentials: true			// 允许cookie
        Access-Control-Max-Age: 100000					// 预检有效期，期间内不需要发送预检请求

安全

XSS

定义：Cross Site Script (跨站脚本攻击)，为了和层叠样式表(Cascading Style Sheet)有所区分，因而在安全领域叫做 XSS。

危害：攻击者可以通过注入恶意脚本获取用户的 Cookie 信息

分类

反射型

将脚本注入到页面中，引诱其点击触发

存储型

服务器端：将脚本注入到服务器端，每次服务器处理时触发

DOM型
```
客户端：修改DOM结构
```

防范

CSP (Content Security Policy)：在meta中设置CSP额外保护层，指定有效域才可访问加载
HTTP only：设置带有HTTP only属性的Cookie将禁止JS访问，只能通过HTTP形式访问
输入验证(表单验证)：验证< >
输出验证(服务器返回内容验证):

定义：Cross Site Request Forgery (跨站请求伪造)；劫持用户Cookie，向服务器攻击

特点：攻击者只能给服务器发送请求，而无法窃取Cookie本身。

防御：

验证码
后端根据HTTP Referer字段来检查其请求源地址
Token验证：在请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token

Authroization

Cookie的一些安全设置

Cookie定义：服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上，主要用于

会话状态管理（用户状态）
个性化设置

说说Cookie的设置方式？常见的cookie参数有哪些？

前端cookie设置与后端cookie设置

后端cookie设置更加安全，前端设置更加符合直觉，但前端设置可能导致cookie被篡改

Cookie类别：

每个 Cookie 都会有与之关联的域，这个域的范围一般通过 donmain 属性指定

Session Cookie：无需指定Expired && Max-Age
Permanate Cookie：可以指定Expired && Max-Age

Session

基于Session认证的问题

服务端开销增大——session保存在内存中
不便于分布式，扩展能力降低——只能从存储的服务器认证
易遭受CSRF——基于cookie识别用户，若cookie被截取，用户会遭受跨站请求攻击

Token

Token的登录鉴权是怎么做的

优势：基于token认证，便于扩展，不挑服务器——对称解密

Token(JWT)

jwt通过加密算法，基于signature，secret key结合数据进行加密，结果为三段，以点分割

注意事项

token payload不能存放敏感信息：如果jwt的密钥、加密算法泄漏，那么数据可以被反向解析出来，所以token中的payload也不能放敏感信息
私钥不能泄漏
尽量使用https

优点：

格式：JSON格式，通用于多种语言
大小：占用空间小，便于传输
可编辑：payload可存储额外的信息（非敏感
储存：不需要服务端保存信息

JWT组成：

let header = "..."
let payload = "..."

let encodingString = base64UrlEncode(header) + '.' + base64UrlEncode(payload)
let signature = MHACSHA256(encodingString, secret) // 生成token的第三部分

const wholeToken = encodingString + '.' + signature

header 指定算法

{
	'typ':'jwt', // 声明类型
	'alg':'HS256' // 一般使用HMAC SHA256声明
}
随后进行base64加密（可对称解密）

payload 指定数据

有效信息（一般不存储敏感信息，均为对称解密，）
	标准声明
	公共声明（业务信息，可在客户端解密
	私有声明（消费者与提供者共同定义的声明，base64对称加密，属于明文

iss: jwt签发者
sub: jwt面向的用户
aud: jwt接收jwt的一方
exp: 过期时间，必须大于签发时间
nbf：定义在什么时间前的jwt不可用
iat：jwt签发时间
jti：jwt的id，用来作为一次性的token，避免重放攻击

signature 指定签名

JWT依赖密钥，对于颁发方的身份验证和授权过程需要安全可靠的。攻击者可能会伪造 JWT。

设置完header与payload，通过密钥进行加密，生成签名：
	header（base64
	payload（base64
	secret

密钥的保存与签发都只属于服务端，若客户端知道了密钥，就可以自己签发jwt

过期时间

过期时间（exp）字段，但是服务端需要验证这个字段以防止使用过期的令牌。如果服务端未正确验证过期时间，攻击者可以重放过期的 JWT。

使用

请求头中加入头信息

Headers:{
	"Authorization": `Bearer ${token}`
}

Proxy

如何理解前端的代理服务器(proxy)？

代理服务器通过将输入转发给不同的输出，实现代理功能
本质上是将网络请求通过中间件转发，实际上是请求转发的一种模式
前端开发时，基于配置的proxy易用高效，可以在开发环境下带来更为流畅和高效的体验，具体来讲，区分了不同的根级接口，尤其在协作开发中，对于接口环境切换相当便捷

笔记

1.1 背景

四层模型

应用层——应用数据
平台层——整合数据
网络层——传输数据
感知层——产生数据

名词概念
- 物联网：
  - 基于互联网，扩大了互联网范围。实现的是物品<=>物品的链接。互联网实现的是计算机到计算机之间的链接
  - 实现技术
```
——射频识别（RFID）
——传感器
——嵌入式操作系统

前两个解决的是数据的收集，嵌入式系统解决的是数据的加工
```
- 大数据：
  - 在数据的获取、储存、管理、分析等方面规模大大超过原有的数据库软件工具能力的数据集合。。
    - 特点：
      - 高数据规模（最低以TB级别）
      - 高数据流转
      - 多样数据类型
      - 价值密度低
    - 重点是算法，难度很大
```
收集 =》 传输 =》 储存 =》 处理 =》 分析 =》 检索 =》 挖掘 =》 应用
```
- 云计算：
  - 整合的计算资源池——多台服务器集中，形成资源池，并通过internet向外提供服务
- AI：
  - 各类环境中执行拟人任务，高智慧任务
```
分类
	弱人工智能
	强人工智能
	超人工智能
特点
	输入——大数据（通过大数据整合计算，总结智慧）
	输入——算法（神经网络，深度学习）——如何学习与应用数据
	输入——计算能力（云计算）
	输出——应用场景
```
- 5G
```
大带宽
低延时
万物互联
```

1.2网络协议基础

协议的概念=>协议由标准化组织管理=>常见的标准化组织=>协议标准=>TCP/IP OSI IPX等 => 均为分层模型 => 分层的目的原因 =>每一层的原因原理机制（封装与解封装）

协议
- 解释：协议就是一套规则，一个约定——实现达成一个详细的约定，并遵循同一套约定标准，以此进行后续处理
- 存在形式：程序

数据通信标准

事实标准/协议——未被组织承认，但都在用

法定标准——法律规定

ISO		国际标准化组织			  制定各行各业的标准
IEEE	电子电器工程师协会		802.3 有限通信协议集  802.11无线通信协议集（WIFI就是采用这个协议）
IETF	INTERNET工程任务委员会
	产生两种文件：“互联网草案 Internet draft”（任何人都可提交，相当于idea） 和 RFC（request for comments）历史存档（如802.1Q Vlan协议）
ANSI	美国国家标准局
EIA/TIA 电子工业协会
ITU		国际电信联盟

世界公认的互联网之父们

罗伯特·泰勒 && 拉里·罗伯茨——ARPA NET

蒂姆·伯纳斯·李——HTTP(WWW——World wide web)

温顿·瑟夫&&罗伯特·卡恩——TCP / IP     This is for everyone

罗伯特·梅特卡夫——以太网（局域网）
伦纳德·克兰罗克——分组交换 && 第一个网络数据

TCP/IP模型

TCP/IP
	Transmission Control Protocol and Internet Protocol  	1969年提出,拥有实际实用价值，也是唯一幸存者
	（五层 或者 四层）
	应用层
		应用层：软件
		表示层
			解决不同操作系统间的通信和语法问题
			解决的需求：转化为标准格式
		会话层：建立和管理应用程序之间的通信
			解决的需求：会话通信


	传输层
		原因：网络间数据发送会出现丢包的问题，数据传输是不可靠的
		实现：保证数据报文正确传输
		功能：
			1、面向链接
			2、面向无连接
		解决的需求：不同的网络节点数据传输中保证数据可靠
	
	网络层
		实现：不同局域网之间发送数据，让数据从一个网络到另一个网络
		功能：
			1、寻找最佳路径（路由）
			2、寻址（IP地址）
		解决的需求：不同网络之间如何选择路径，并连通数据
	数据链路层	解决内部网络的通信——保证硬件间数据正确
	
		原因：传输时会有数据损耗，数据可能错误
		目的：扩展不同介质之间的传输。确保传输的比特流正确，并且针对错误有纠错功能
		实现：将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路
	      功能：
	      	1：确保数据正确
	      	2：寻址（MAC）
	      解决的需求：
	      	使物理信号无差错传递
	物理层
		解释：硬件间的通信（接口类型，传输介质的速率）
		目的：传输比特流（数模转换与模数转换：1,0=>电流的强弱=>1,0）
		解决的需求：物理信号之间的传递，使物理线路通畅


其它同时代模型：
    OSI
        解决网络间兼容性的问题。将服务，接口，协议独立出来。			1984年提出，并不实用，只有理论价值
    IPX/SPX
    SNA

思考：为什么要分层

网络通信非常复杂：
	1、数据传输本身 —— 以010101001010二进制传输
	2、网络传输本身 —— 降低复杂度
应用要求
	相互独立于不同的应用需求
标准化
	促进标准化
厂商兼容性
	简化网络操作
学习成本/操作性
	便于学习与操作
模块化————————高内聚 低耦合
	内聚：
	耦合：层与层之间相互独立，上下层之间彼此耦合度低，互不干扰

思考：分层模型的原理

封装与解封装——套娃
	发送时：不停加入外层封装
	接收时：不停拆除外层封装

发生在互联网的任何一次通信都是封装与解封装的过程

1.3 (TCP/IP）应用层

软件与硬件

应用层
---------↑软件方向（软件开发）   ↓硬件方向（通信、传输）
传输层
网络层
接口层

应用层协议(application layer protocol)
- 解决的需求：运行在不同端系统上的应用程序进程如何相互传递报文
Part1 工作原理
- 协议 != 程序
  - 程序调用应用层的协议，而不是每一个程序都有一个协议
  - 如：网易邮箱、QQ邮箱调用POP3协议
- 特点：数量在所有层里最多
- 目的：根据不同的应用层协议产生应用层数据
- 软件服务模式：
  - 客户机/浏览器 CS架构或者 BS架构（client-server / browser-server）
    - 客户端请求服务器
    - 服务器相应客户端
    - （浏览器是CS架构，浏览器本身也是客户端）
  - P2P（对等体结构）
    - 每个人的电脑都可以当服务器，也可以当客户端
    - 每个人的计算机都可以访问其他人计算机的内容，同样自己的计算机都可以相应其他人的访问，达到共享
    - （下载是典型的p2p应用）
  - 混合模式
    - 根服务器 + 主机
    - 以下载为例：主机=>访问根服务器=>返回最佳P2P下载路径=>主机同时对N个主机进行访问，获取下载资源
Part2 HTTP && HTTPS
- HTTP——超文本传输协议(HyperText Transfer Protocol )
- 架构：CS架构（User - Web）被动式服务（不请求，无资源）
- 基础：TCP
- 前提：
  - 位置（信息资源在服务器的位置）——URL（统一资源定位符）
  - 规则（CS之间如何沟通）——HTTP
  - 呈现（返回的信息如何组织起来）——HTML
- 资源请求：
- 功能状态码
- HTTP特点
  - 无状态——对客户端无状态储存（访问一个web需要反复进行登录——每次都要进行同服务器的三次握手四次挥手建立连接）
  - 无连接——因为无状态，所以无法储存链接
  - 基于请求与相应——客户机-服务器模式
  - 明文通信——请求与相应不会同通信方进行确认，无法保证数据完整性
- HTTPS特点
  - 基于HTTP，通过SSL或者TLS进行加密处理——提供身份验证和数据完整性保护
  - 过程：
```
    （C）请求下载服务器CA证书/根证书（CA中有公钥）=>（C)使用公钥加密数据传递服务器=>（S）使用私钥解密，返回数据                即SSR
    ```
```

Part3 DNS协议

域名解析协议（Domain Name System）
架构：CS
功能：域名=>IP地址
（多用UDP，主服务器同备用服务器之间同步数据时，使用TCP）

查询流程：

1、查看本地的hosts文件，如果host文件里有直接使用host文件里的记录——/system32/etc/host
2、启动DNS客户端——查询DNS服务器地址=>查询本地DNS服务器
3、如果本地均无，向前一个DNS服务器查找，直到查找到根服务器

Part4 其它协议
- FTP（File Transfer Protocol）
- SMTP（Simple Mail Transfer Protocol） && POP3（Post Office Protocol 第三版邮局协议）
- Telnet——远程登录协议

1.4 (TCP/IP)传输层

传输层位于TCP/IP协议的第四层，为App提供服务。定义了APP之间端到端的连通性。

Part1 端到端通信

“地址”的概念在所有层中，所有计算机语言，编程中都存在。
传输层的“地址”，即端口号——也即程序地址
功能：用来识别同一计算机中进行通信的不同应用层服务，实现指定应用程序到指定应用程序之间的通信
每一个协议拥有一个端口号

源端口号是随机的，且必须大于1023

请求包：源端口>1023
		Source Port:5002
		Destination Port:443

相应包：源端口<1023
        Source Port:443
        Destination Port:5002

会话

A向B通信
A发送数据，源端口号（随机）2000，目标端口号80
B收到数据
B返回数据时，源端口号为80，目标端口号为2000

通过五个参数甄别一个通信

IP（源IP、目标Ip）
协议号
端口号（源端口号，目标端口号）

端口号

长度：16位，共65536个
范围：0-65535

指派方式

熟知端口：0-1023   IANA占用，公共协议
注册端口：1024-49151   IANA不指派、不控制。在IANA注册以防重复
动态端口（临时端口）：49152-65535  可以通过任意进程来使用

Windows下查看端口号占用情况——windows端口表
```
netstat -aon
```

Part2 TCP可靠性

TCP提供面向链接（通信时双方都可确保对方均接受了链接）、可靠的服务。
UDP提供面向无连接服务（A对B发送信息，不考虑是否真的收到）。
可靠性（通过TCP首段报文说明文件来实现以下功能）
- 面向链接（体现在链接的建立与拆除上）
- 最大报文肠长度
- 确认传输机制
- 流量控制
- 首部数据校验和
TCP报文

三次握手*建立链接）与四次挥手（拆除链接）

SYN：请求建立链接
FIN：Finish

为什么是四次才能拆除链接：
	拆除时Server端需要先把数据全部发送完毕，再去请求断开链接
	如果直接请求断开链接，数据就会被腰斩
	TCP半关闭状态

分段与重组

分段后，潜在的包丢失的成本会将至最小，重发时的工作量也小；若不分段，丢包会导致整个包都丢，导致整个包重传，效率过低；

为什么要分段，重组：
	目的：提升数据传输效率，降低故障率

流程：
	1、确定最大报文长度——通过MSS
	2、确定重组的依据——通过序列号


MTU：物理链路上最大承担的数据链路量（数据联络层的概念）
MSS(Max Segment Size)最大报文尺寸=MTU-网络层数据包头-传输层数据包头 = 1500 - 20 - 20 = 1460字节
	在三次握手时，确定MSS值

拆分时,会在数据中添加统一标识符：序列号
	A ----------B-------------C
0-1460       1461-...		...-...

确认与重传

确认：基于序列号
重传：
	时间间隔（三次握手时定义）——根据C/S网络环境动态生成

流量控制

滑动窗口：
	为什么有滑动窗口——提高吞吐量，减少排队与等待，

慢启动：
	避免启动时，高并发导致的网络高峰

Part3 TCP与UDP区别
- 代表：微信、短信
- 不需要建立链接、不需要维护状态
- TCP——数据流协议，TCP会对数据进行分段，而UDP不会
- UDP——数据报协议

1.5 (TCP/IP)网络层

实现终端节点到节点之间的通信（个人主机）

核心包括： IP(编址)寻址、路由、分包与组包

数据 = 传输层head + 应用层head + 应用层数据

Part1 点到点通信 && Part2 IP地址

IP地址使得异构网络之间得以连通，让不同的网络在同一个规则下通信

点分十进制
V4地址总数：43亿个

五类地址：

ABC类的私有地址

A类私有 10.0.0.0		-   10.255.255.255            10网段
B类私有 172.16.0.0		-   172.31.255.255			  172.16-172.32网段（不包含）
C类私有 192.168.0.0 	-   192.168.255.255		  192.168网段

掩码

1的部分为网络，0的部分为主机

Part3 路由

路径=>路由=>路由器=>路由表
告诉数据包怎么到达目的网络

解决的三个问题

1、目标是什么     目的地址+子网掩码
2、从哪个方向走	输出接口
3、下一站在哪		下一跳

类型

直连
静态
动态（ARP、OSPF、IS-IS、BGP）

Part4 Ip分片

为什么要在网络层还要分片？

主要是对传输层UDP的补充，UDP是整个发过来的。

MTU在Internet中为1500，在FDDI中是4352，在ATM中为9180。上一层可能传输比MTU更多的数据量。

IP报文中专门用来分片的字段

标识位、标志位、片偏移

标识位：
	被分片后被打上统一表示
标志位：
	DF——不分片位
	MF——更多分片位
片偏移：
	类似于TCP中的序列号，对分片进行重组

1.6 (TCP/IP) 接口层

Part1: 数据链路层

数据链路层实现的是逐跳传递，确保物理信道可以正常发送数据
功能：帧发送与帧接收、用户数据帧的组装与分解、物理层信息监测、信道闲忙、数据链路的收发管理
地址：MAC地址
（不同操作系统表示的MAC地址方式不同，但都是十六进制）

48位十六进制数

第一位：确定单播地址还是多播地址   0：单播  1：多播
第二位：确定是全局地址还是本地地址 0：全局  1：本地
3-24位：厂商识别码    IEEE管理，保证厂家之间不重复
25-48位：厂商内识别码 厂商管理，保证产品之间不重复

链路类型

共享介质型网络：
	所有PC共用一条线：争用，令牌传递。
	争用/CSMA(载波监听多路访问)：边听边发 冲突停发 随机延迟等待
非共享介质型网络：
	交换式以太网——通过交换机进行通讯
	（有线）两种格式：
		802.3  IEEE
		Ethernet2
	（无线）以太网 IEEE802.11系列协议

计算机网络 ​

浏览器URL回车后发生了什么 ​

三次握手与四次挥手 ​

HTTP基础 ​

http ​

https ​

SSL/TLS ​

webHooks 与 webSockets ​

HTTP缓存 ​

前端缓存 ​

后端缓存 ​

问题 ​

跨域 ​

同源的定义 ​

跨域方式 ​

CORS ​

安全 ​

XSS ​

CSRF（Cookie） ​

Authroization ​

Cookie ​

Session ​

Token ​

Token(JWT) ​

Proxy ​

笔记 ​

1.1 背景 ​

1.2网络协议基础 ​

1.3 (TCP/IP）应用层 ​

1.4 (TCP/IP)传输层 ​

1.5 (TCP/IP)网络层 ​

1.6 (TCP/IP) 接口层 ​

计算机网络

浏览器URL回车后发生了什么

三次握手与四次挥手

HTTP基础

http

https

SSL/TLS

webHooks 与 webSockets

HTTP缓存

前端缓存

后端缓存

问题

跨域

同源的定义

跨域方式

CORS

安全

XSS

CSRF（Cookie）

Authroization

Cookie

Session

Token

Token(JWT)

Proxy

笔记

1.1 背景

1.2网络协议基础

1.3 (TCP/IP）应用层

1.4 (TCP/IP)传输层

1.5 (TCP/IP)网络层

1.6 (TCP/IP) 接口层