趣谈网络协议-学习笔记3

=Start=

缘由:

极客时间专栏地址:「趣谈网络协议」。建议想较为系统的梳理网络协议相关知识的同学都自己去订阅一下该专栏,相较于你可以学习到的知识而言,价格相当便宜了。


记录本文(很可能分成多篇持续总结、整理)的目的很简单——希望在学习了一样知识之后能有个学习笔记之类的东西留下,一来是加深学习印象和效果;二来是方便以后有个参考(随着年龄的增长,需要处理问题的增多,个人的记忆力会越来越不可靠,及时文档化是应对这种问题的有效方式之一)。

正文:

参考解答:
最重要的传输层
  • 第10讲 | UDP协议:因性善而简单,难免碰到城会玩
# TCP 和 UDP 有哪些区别?
一般面试的时候我问这两个协议的区别,大部分人会回答,TCP 是面向连接的,UDP 是面向无连接的。
TCP 提供可靠交付;UDP 继承了 IP 包的特性,不保证不丢失,不保证按顺序到达。
TCP 是面向字节流的;UDP 继承了 IP 的特性,基于数据报的,一个一个地发,一个一个地收。
TCP 是可以有拥塞控制的;UDP 就不会,应用让我发,我就发,管它洪水滔天。
TCP 其实是一个有状态服务;UDP 则是无状态服务。
# UDP 包头是什么样的?
源端口号(16位)
目的端口号(16位)
UDP长度(16位)
UDP校验和(16位)
# UDP 的三大特点
沟通简单
轻信他人
没有拥塞控制
# UDP 的三大使用场景
第一,需要资源少,在网络情况比较好的内网,或者对于丢包不敏感的应用。
第二,不需要一对一沟通,建立连接,而是可以广播的应用。
第三,需要处理速度快,时延低,可以容忍少数丢包,但是要求即便网络拥塞,也毫不退缩,一往无前的时候。
# 基于 UDP 的“城会玩”的五个例子
“城会玩”一:网页或者 APP 的访问——比如QUIC(全称Quick UDP Internet Connections,快速 UDP 互联网连接)是 Google 提出的一种基于 UDP 改进的通信协议,其目的是降低网络通信的延迟,提供更好的用户互动体验。
“城会玩”二:流媒体的协议
“城会玩”三:实时游戏
“城会玩”四:IoT 物联网
“城会玩”五:移动通信领域
  • 第11讲 | TCP协议:因性恶而复杂,先恶后善反轻松
# TCP 包头格式
通过对 TCP 头的解析,我们知道要掌握 TCP 协议,重点应该关注以下几个问题:
顺序问题,稳重不乱;
丢包问题,承诺靠谱;
连接维护,有始有终;
流量控制,把握分寸;
拥塞控制,知进知退。
# TCP 的三次握手
Client: SYN
Server: SYN/ACK
Client: ACK
# TCP 四次挥手
Client: FIN
Server: ACK
Server: FIN
Client: ACK
# TCP 状态机
将连接建立和连接断开的两个时序状态图综合起来,就是这个著名的 TCP 的状态机。
  • 第12讲 | TCP协议:西行必定多妖孽,恒心智慧消磨难
# 如何做个靠谱的人?
TCP 想成为一个成熟稳重的人,成为一个靠谱的人。那一个人怎么样才算靠谱呢?咱们工作中经常就有这样的场景,比如你交代给下属一个事情以后,下属到底能不能做到,做到什么程度,什么时候能够交付,往往就会有应答,有回复。这样,处理事情的过程中,一旦有异常,你也可以尽快知道,而不是交代完之后就石沉大海,过了一个月再问,他说,啊我不记得了。
对应到网络协议上,就是客户端每发送的一个包,服务器端都应该有个回复,如果服务器端超过一定的时间没有回复,客户端就会重新发送这个包,直到有回复。
# 如何实现一个靠谱的协议?
# 顺序问题与丢包问题
# 流量控制问题
# 拥塞控制问题
# 小结
顺序问题、丢包问题、流量控制都是通过滑动窗口来解决的,这其实就相当于你领导和你的工作备忘录,布置过的工作要有编号,干完了有反馈,活不能派太多,也不能太少;
拥塞控制是通过拥塞窗口来解决的,相当于往管道里面倒水,快了容易溢出,慢了浪费带宽,要摸着石头过河,找到最优值。
  • 第13讲 | 套接字Socket:Talk is cheap, show me the code
# 基于 TCP 协议的 Socket 程序函数调用过程
客户端    服务端
socket()  socket()
             bind()
             listen()
connect() accept()
write()    read()
read()    write()
# 基于 UDP 协议的 Socket 程序函数调用过程
对于 UDP 来讲,过程有些不一样。UDP 是没有连接的,所以不需要三次握手,也就不需要调用 listen 和 connect,但是,UDP 的的交互仍然需要 IP 和端口号,因而也需要 bind。
客户端   服务端
socket() socket()
bind()
sendto() recvfrom()
recvfrom() sendto()
# 服务器如何接更多的项目?
{本机 IP, 本机端口, 对端 IP, 对端端口}
理论上的最大连接数:
服务器通常固定在某个本地端口上监听,等待客户端的连接请求。因此,服务端端 TCP 连接四元组中只有对端 IP, 也就是客户端的 IP 和对端的端口,也即客户端的端口是可变的,因此,最大 TCP 连接数 = 客户端 IP 数×客户端端口数。对 IPv4,客户端的 IP 数最多为 2 的 32 次方,客户端的端口数最多为 2 的 16 次方,也就是服务端单机最大 TCP 连接数,约为 2 的 48 次方。
当然,服务端最大并发 TCP 连接数远不能达到理论上限。首先主要是文件描述符限制,按照上面的原理,Socket 都是文件,所以首先要通过 ulimit 配置文件描述符的数目;另一个限制是内存,按上面的数据结构,每个 TCP 连接都要占用一定内存,操作系统是有限的。
方式一:将项目外包给其他公司(多进程方式)
方式二:将项目转包给独立的项目组(多线程方式)
方式三:一个项目组支撑多个项目(IO 多路复用,一个线程维护多个 Socket)
方式四:一个项目组支撑多个项目(IO 多路复用,从“派人盯着”到“有事通知”)
epoll 这种通知方式使得监听的 Socket 数据增加的时候,效率不会大幅度降低,能够同时监听的 Socket 的数目也非常的多了。上限就为系统定义的、进程打开的最大文件描述符个数。因而,epoll 被称为解决 C10K 问题的利器。
参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4016.html

《趣谈网络协议-学习笔记3》上有1条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注