今天整理《趣谈网络协议》的笔记，先整体记录再单独删减。

简述一个网络请求

也是从一个http请求开始。
输入网址，会通过dns进行查找，找到ip地址。
有了目标地址，浏览器就可以打包请求，普通请求走http协议，加密请求走https。【这里http头封装好了】
dns，http，https所在的层称为应用层。应用层封装好，把包发给下一层，这个过程通过 socket 变成实现。
下一层是传输层，分为无连接的udp协议，面向连接的tcp。面向连接就是会保证包能够到达目的地，不能到达就重新发送，直到到达。
tcp协议有两个端口，一个是浏览器监听端口，一个是电商服务端端口，通过端口判断包发给哪个进程。【tcp头封装好，浏览器123端口，电商443端口。传输层封装结束】
浏览器把包交给操作系统的【网络层】。网络层协议是ip协议，有两边的ip地址。【ip头封装完，包含两边的ip】
操作系统根据目标ip判断是不是远程的，如果是就要发给网关。这里【mac头封装完。客户端的mac和网关的mac】
网关往往是一个路由器，根据路由表查询，最终发出去到服务端mac层，再一层层卸掉ip，到tcp层，这里要应答表明收到。如果过一段时间没有收到，客户端会再发一次。

网络分层

复杂程序都要分层。
不同层用协议沟通。
tcp在忙活三次握手时候，ip和mac在干嘛，还是每次都触发完整过程。

tcp和udp

tcp提供可靠交付，通过tcp发送得到数据，无差错不丢失，不重复，按序到达。
udp不保证不丢失，不保证按顺序到达。

tacp面向字节流，发的是一个流，没头没尾。把ip包变成流。
udp一个一个发，一个一个收。

tcp可以拥塞控制，如果包丢了或者网络不好，会控制发包。
udp按固定速率发送。

tcp有状态，记录发送，接受的状态。
udp无状态，发出去就发出去了，不在乎发送到了没有。

基于此，udp适合的场景：

• 需要资源好，网络状况好的内网，或丢包不敏感的应用。dhcp
• 不需要一对一，可以广播的应用。
• 处理速度快，时延低，可以少数丢包

google基于udp改进的quic, quick udp internet coonnections 快速udp网络连接。降低网络通信延迟，提供更好的用户互动体验。

流媒体rtmp，基于tcp对直播不合适。老的视频丢了就丢了，直播实时性要求高，宁可丢包不要卡顿。网络不好需要选择性的丢包。

实时游戏。自定义的可靠udp，自定义重传策略

IoT物联网。移动通信等。

tcp

tcp三次握手

场景： 你好我是a，你好a我是b，你好b
为什么是三次？
假设网络不可靠。a发一个连接出去没回应，有可能丢包了，有可能超时了，有可能b没有反应。a需要不断发。
b应答，也可能没反应，或者碰巧a决定放弃了。
a需要再应答一次，保证b心里有底。

四次握手也可以，四百次握手也可以，但是这也不能就保证就考考了，只要信息有去有回。
三次握手除了建立连接，也是为了沟通tcp包序号。连接开始的需要是变化的。

四次挥手

• A: B啊，我不玩了
• B: 好，我知道了。

B这时候不能直接关闭，有可能b还没处理完，还可以给a发数据。

• B: 好，我也不玩了，再见
• A： 再见。

中间有一些细节来处理状态，究竟有没有断开。

http

开始应用层。
目前http1.1 的keep-alive 建立的tcp连接可以在

http请求体

负载均衡。动态redis，静态varnish
http头部分

http2

对http头进行一定的压缩，建立索引表。
把传输信息分割成更小的消息和帧。

CDN

动态cdn如何实现？

• 边缘计算，生鲜超市模式。既然是动态的，把逻辑和存储也放到节点上，定时从源站同步。
• 路径优化，冷链运输。数据源站生成，下发通过cdn，找到离用户近的节点。

其他的就略过了，不太感兴趣，也有点难。