青训营笔记——打开抖音互联网会发生什么

user4882502551904
225 阅读19分钟

go语言——打开抖音互联网会发生什么——青训营笔记

概述

课程pptt bytedance.feishu.cn/file/boxcne…

学员手册：juejin.cn/post/709712…

本节课程主要以刷抖音时的底层互联网交互作为切入点，带大家回顾了计算机网络的相关知识。课程主要分为四个方面：

  1. 网络接入协议
  1. 网络传输协议
  1. 网络优化
  1. 网络稳定

网络接入协议/概念

  • MAC地址：1、 MAC地址就是在媒体接入层上使用的地址，也叫物理地址、硬件地址或链路地址，由网络设备制造商生产时写在硬件内部。MAC地址与网络无关，即无论将带有这个地址的硬件（如网卡、集线器、路由器等））接入到网络的何处，都是相同的MAC地址 2、MAC地址通常表示为12个16进制数，每2个16进制数之间用冒号隔开，如08：00：20：0A：8C：6D就是一个MAC地址，其中的前16位16进制数08：00：20代表网络硬件制造商的编号，由IEEE分配，后6位16进制数0A:8C:6D代表该制造商的某个网络产品（如网卡）的系列号。
  • 路由协议:在互联网中，一个自治系统(AS)是一个有权自主地决定在本系统中应采用何种路由协议的小型单位。这个网络单位可以是一个简单的网络也可以是一个由一或多个普通的网络管理员来控制的网络群体，它是一个单独的可管理的网络单元（例如一所大学，一个企业或者一个公司个体）。一个自治系统将会分配一个全局的唯一的16位号码，有时我们把这个号码叫做自治系统（ASN）
  • ARP协议:在任何时候，一台主机有IP数据报文发送给另一台主机，它都要知道接收方的逻辑（IP）地址。但是IP地址必须封装成帧才能通过物理网络。这就意味着发送方必须有接收方的物理（MAC）地址，因此需要完成逻辑地址到物理地址的映射。而ARP协议可以接收来自IP协议的逻辑地址，将其映射为相应的物理地址，然后把物理地址递交给数据链路层。 ARP有两种映射方式,静态映射和动态映射
  • IP协议:IP是TCP/IP协议族中最为核心的协议，它提供无连接的不可靠的连接。所有的 TCP、UDP、ICMP及IGMP数据都以I P数据报格式传输。本文IP指IPv4。
  • NAT：助于NAT，私有（保留）地址的"内部"网络通过路由器发送数据包时，私有地址被转换成合法的IP地址，一个局域网只需使用少量IP地址（甚至是1个）即可实现私有地址网络内所有计算机与Internet的通信需求。 当内部网络中的一台主机想传输数据到外部网络时，它先将数据包传输到NAT路由器上，路由器检查数据包的报头，获取该数据包的源IP信息，并从它的NAT映射表中找出与该IP匹配的转换条目，用所选用的内部全局地址（全球唯一的IP地址）来替换内部局部地址，并转发数据包。 当外部网络对内部主机进行应答时，数据包被送到NAT路由器上，路由器接收到目的地址为内部全局地址的数据包后，它将用内部全局地址通过NAT映射表查找出内部局部地址，然后将数据包的目的地址替换成内部局部地址，并将数据包转发到内部主机

网络传输协议

  • DNS：如果说ARP协议是用来将IP地址转换为MAC地址，那么DNS协议则是用来将域名转换为IP地址（也可以将IP地址转换为相应的域名地址） IP地址是面向主机的，而域名则是面向用户的。

1、域名的层次结构 域名系统必须要保持唯一性。 为了达到唯一性的目的，因特网在命名的时候采用了层次结构的命名方法：

  1. 每一个域名（本文只讨论英文域名）都是一个标号序列（labels），用字母（A-Z，a-z，大小写等价）、数字（0-9）和连接符（-）组成
  2. 标号序列总长度不能超过255个字符，它由点号分割成一个个的标号（label）
  3. 每个标号应该在63个字符之内，每个标号都可以看成一个层次的域名。
  4. 级别最低的域名写在左边，级别最高的域名写在右边。 域名服务主要是基于UDP实现的，服务器的端口号为53。

eg :我们熟悉的，www.baidu.com\

  1. com: 一级域名. 表示这是一个企业域名。同级的还有 “net”(网络提供商), “org”(⾮非盈利组织) 等。\
  2. baidu: 二级域名，指公司名。\
  3. www: 只是一种习惯用法。
  • UDP：UDP提供不可靠服务，具有TCP所没有的优势：

UDP无连接，时间上不存在建立连接需要的时延。空间上，TCP需要在端系统中维护连接状态，需要一定的开销。此连接装入包括接收和发送缓存，拥塞控制参数和序号与确认号的参数。UCP不维护连接状态，也不跟踪这些参数，开销小。空间和时间上都具有优势。 举个例子：

DNS如果运行在TCP之上而不是UDP，那么DNS的速度将会慢很多。 HTTP使用TCP而不是UDP，是因为对于基于文本数据的Web网页来说，可靠性很重要。 同一种专用应用服务器在支持UDP时，一定能支持更多的活动客户机。

分组首部开销小**，TCP首部20字节，UDP首部8字节。

UDP没有拥塞控制，应用层能够更好的控制要发送的数据和发送时间，网络中的拥塞控制也不会影响主机的发送速率。某些实时应用要求以稳定的速度发送，能容 忍一些数据的丢失，但是不能允许有较大的时延（比如实时视频，直播等）

UDP提供尽最大努力的交付，不保证可靠交付。所有维护传输可靠性的工作需要用户在应用层来完成。没有TCP的确认机制、重传机制。如果因为网络原因没有传送到对端，UDP也不会给应用层返回错误信息

UDP是面向报文的，对应用层交下来的报文，添加首部后直接乡下交付为IP层，既不合并，也不拆分，保留这些报文的边界。对IP层交上来UDP用户数据报，在去除首部后就原封不动地交付给上层应用进程，报文不可分割，是UDP数据报处理的最小单位。 正是因为这样，UDP显得不够灵活，不能控制读写数据的次数和数量。比如我们要发送100个字节的报文，我们调用一次sendto函数就会发送100字节，对端也需要用recvfrom函数一次性接收100字节，不能使用循环每次获取10个字节，获取十次这样的做法。

UDP常用一次性传输比较少量数据的网络应用，如DNS,SNMP等，因为对于这些应用，若是采用TCP，为连接的创建，维护和拆除带来不小的开销。UDP也常用于多媒体应用（如IP电话，实时视频会议，流媒体等）数据的可靠传输对他们而言并不重要，TCP的拥塞控制会使他们有较大的延迟，也是不可容忍的

  • TCP：TCP 是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。

所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如 IP 地址、端口号等。

TCP 可以看成是一种字节流，它会处理 IP 层或以下的层的丢包、重复以及错误问题。

在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在 TCP 头部。

TCP 提供了一种可靠、面向连接、字节流、传输层的服务，采用三次握手建立一个连接。采用四次挥手来关闭一个连接。

三次握手和四次挥手的状态转换如下图所示

20200227123302629.jpg 为什么要“三次握手，四次挥手” 三次握手 换个易于理解的视角来看为什么要三次握手。

客户端和服务端通信前要进行连接，“三次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。

从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。

而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。

第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。

而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。

经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。

每次都是接收到数据包的一方可以得到一些结论，发送的一方其实没有任何头绪。

我虽然有发包的动作，但是我怎么知道我有没有发出去，而对方有没有接收到呢？

而从上面的过程可以看到，最少是需要三次握手过程的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论。

其实每次收到网络包的一方至少是可以得到：对方的发送、我方的接收是正常的。

而每一步都是有关联的，下一次的“响应”是由于第一次的“请求”触发，因此每次握手其实是可以得到额外的结论的。

比如第三次握手时，服务端收到数据包，表明看服务端只能得到客户端的发送能力、服务端的接收能力是正常的。

但是结合第二次，说明服务端在第二次发送的响应包，客户端接收到了，并且作出了响应，从而得到额外的结论：客户端的接收、服务端的发送是正常的。

四次挥手 TCP 连接是双向传输的对等的模式，就是说双方都可以同时向对方发送或接收数据。

当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个 ACK，此时一个方向的连接关闭。

但是另一个方向仍然可以继续传输数据，等到发送完了所有的数据后，会发送一个 FIN 段来关闭此方向上的连接。接收方发送 ACK 确认关闭连接。

注意，接收到 FIN 报文的一方只能回复一个 ACK, 它是无法马上返回对方一个 FIN 报文段的，因为结束数据传输的“指令”是上层应用层给出的，我只是一个“搬运工”，我无法了解“上层的意志”。

  • HTTP：HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。

支持客户/服务器模式。

简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

灵活：HTTP允许传输任意类型的数据对象。传输的类型由Content-Type加以标记。

无连接：无连接是表示每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 注意： HTTP1.1版本后支持可持续连接。（我们当前就是HTTP/1.1）通过这种连接，就有可能在建立一个TCP连接后，发送请求并得到回应，然后发送更多的请求并得到更多的回应。通过把建立和释放TCP连接的开销分摊到多个请求上，则对于每个请求而言，由于TCP而造成的相对开销被大大地降低了。而且，还可以发送流水线请求，也就是说在发送请求1之后的回应到来之前就可以发送请求2.也可以认为，一次连接发送多个请求，由客户机确认是否关闭连接，而服务器会认为这些请求分别来自不同的客户端。

无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快

HTTP之URL URL作用：HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。 URL就是浏览器的书写格式。

基本URL包含模式（或称协议）、服务器名称（或IP地址）、路径和文件名，如“协议：//授权/路径?查询”。

URL由三部分组成：资源类型、存放资源的主机域名、资源文件名。 也可认为由4部分组成：协议、主机、端口、路径。

  • HTTPS：是以安全为目标的HTTP[通道]，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
  • HTTP2.0：HTTP2.0的主要目标是通过支持完整的请求与响应复用来减少延迟，通过有效压缩 HTTP 标头字段将协议开销降至最低，同时增加对请求优先级和服务器推送的支持。大幅提升web性能

多路复用 HTTP2.0中，有两个概念非常重要：帧（frame）和流（stream）。 帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流是多个帧组成的数据流。 所谓多路复用，即在一个TCP连接中存在多个流，即可以同时发送多个请求，对端可以通过帧中的表示知道该帧属于哪个请求。在客户端，这些帧乱序发送，到对端后再根据每个帧首部的流标识符重新组装。通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。

HTTP1.0 和 HTTP1.1
  1. 队头阻塞： 下个请求必须在前一个请求返回后才能发出，导致带宽无法被充分利用，后续请求被阻塞（HTTP 1.1 尝试使用流水线（Pipelining）技术，但先天 FIFO（先进先出）机制导致当前请求的执行依赖于上一个请求执行的完成，容易引起队头阻塞，并没有从根本上解决问题）；
  2. 协议开销大： header 里携带的内容过大，且不能压缩，增加了传输的成本；
  3. 单向请求： 只能单向请求，客户端请求什么，服务器返回什么；
  4. HTTP 1.0 和 HTTP 1.1 的区别： 5. HTTP 1.0：仅支持保持短暂的 TCP 连接（连接无法复用）；不支持断点续传；前一个请求响应到达之后下一个请求才能发送，存在队头阻塞 6. HTTP 1.1：默认支持长连接（请求可复用 TCP 连接）；支持断点续传（通过在 Header 设置参数）；优化了缓存控制策略；管道化，可以一次发送多个请求，但是响应仍是顺序返回，仍然无法解决队头阻塞的问题；新增错误状态码通知；请求消息和响应消息都支持 Host 头域
  • QUIC：基于UDP的传输层协议，提供像TCP一样的可靠性。在提高web应用性能上，可以选择在应用层使用HTTP2.0实现多路传输，在物理层使用CDN解决网络拥塞和最后一公里问题。在传输层，目前主要使用TCP，但由于TCP本身的问题（一个充满补丁的丑陋的协议），成为了限制web应用性能的一个瓶颈。

#优势

避免前序包阻塞（HOL阻塞）

多个数据在TCP连接上传输时，若一个数据包出现问题，TCP需要等待该包重传后，才能继续传输其它数据包。但在QUIC中，因为其基于UDP协议，UDP数据包在出问题需要重传时，并不会对其他数据包传输产生影响。

    • 跨网段：配置网关路由。获取网关MAC地址发包

    • 动态路由：BGP/OSPF等，路由表在动态变化
    • 路由是网状的，不一定是对称的

  • ARP协议

    • ARP广播/应答：协议原理
    • 免费ARP：主动广播告知MAC地址
    • ARP代理：虚拟网络/伪造MAC地址 ARP的本质是查找下一跳的mac，不是请求目标地址

  • IP协议

    • IPv4：互联网终端节点的唯一标识
    • IPv6：不仅仅是IP地址长度的增加

  • NAT

    • NAT上网：家用路由器
    • NAT出网：机房内网主机上外网
    • NAT原理：注意不仅仅是源地址变换，源端口/校验和/SEQ等都会变化

网络传输

  • 数据包：本质上是一段内存，里面存储的内存是有序的，一般是按照TCP/IP的多层协议去封装。拆包/封包都是按照协议去写内存/读内存。

网络传输

  • 数据包：本质上是一段内存，里面存储的内存是有序的，一般是按照TCP/IP的多层协议去封装。拆包/封包都是按照协议去写内存/读内存。

  • DNS递归迭代

  • UDP

    • 协议简单
    • 需要考虑可靠性的场景使用复杂

  • TCP

    • 三次握手：确认传输的序列号/MSS/Option字段，建立连接
    • TCP连接：是一个虚拟的概念，本质上两倍维持一段内存，记录连接状态，就是session
    • TCP传输：理解sequence number/acknowledge number
    • 丢包重传：理解丢包怎么感知并重传，理解快速重传发生在什么时候
    • 滑动窗口：课后自学
    • 流量控制：课后自学

  • HTTP

    • HTTP比TCP好在哪里：方便
    • HTTP1.1的优化：长连接是重点

  • HTTPS

    • HTTPS的产生背景：加密/可靠/防劫持
    • SSL/TLS握手：非对称加密/对称加密

网络提速

  • HTTP2.0

    • 多路复用：依然有队头阻塞

  • QUIC

    • QUIC的产生背景和背后思考：

      • 为什么在用户态实现？内核的更新迭代频率较低，不好推广
      • 为什么用UDP？TCP的队头阻塞问题不好解决，推倒重来&复用所有操作系统基本都支持的底层协议

  • 数据中心建设

    • 多运营商接入：同运营商内部访问，避免跨运营商的流量
    • 有边缘机房/汇聚机房/中心机房
  • CDN静态缓存系统：边缘机房的建设，优先访问边缘机房，缓存命中视频/图片等静态内容

  • DSA动态加速系统：分四层/七层动态加速。核心在于利用可控节点做路径探测和规划。

网络稳定

  • 对容灾的理解

  • 网络容灾的具体案例

    • 机房专线故障：环路容灾，避免某条专线故障导致机房孤岛问题（专线是连接各个机房的网络物理路径）

    • 单机房接入节点故障：DNS容灾，摘除故障的节点-字节GTM系统

    • 云控容灾：云端交互，服务器/云上下发命令到终端-字节TNC系统

    • cache容灾：源站不可用，降级到之前的缓存内容-字节TLB/ByteCDN等系统的容灾建设

  • 故障排查

    • 加强故障沟通-明确故障
    • 故障止损要在第一时间做（灾备预案的建设）
    • 熟悉常用的故障排查命令

  • 故障排查的具体案例

    • 服务端配置异常（健康检查异常）

    • 客户端某个例异常（客户端自己配置错误）

    • 外部运营商故障

    • 复杂故障的排查：需要抓包，具体问题具体分析

网络容灾 blog.csdn.net/weixin_4399…

avatar
文章
阅读
粉丝