趣谈网络协议读后感

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

简述一个网络请求

也是从一个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,找到离用户近的节点。

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

扫一扫,分享到微信

请我喝杯咖啡吧~