趣谈网络协议
刘超
网易研究院云计算技术部首席架构师
立即订阅
37977 人已学习
课程目录
已完结 51 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想成为技术牛人?先搞定网络协议!
免费
第一模块 通信协议综述 (4讲)
第1讲 | 为什么要学习网络协议?
第2讲 | 网络分层的真实含义是什么?
第3讲 | ifconfig:最熟悉又陌生的命令行
第4讲 | DHCP与PXE:IP是怎么来的,又是怎么没的?
第二模块 底层网络知识详解:从二层到三层 (5讲)
第5讲 | 从物理层到MAC层:如何在宿舍里自己组网玩联机游戏?
第6讲 | 交换机与VLAN:办公室太复杂,我要回学校
第7讲 | ICMP与ping:投石问路的侦察兵
第8讲 | 世界这么大,我想出网关:欧洲十国游与玄奘西行
第9讲 | 路由协议:西出网关无故人,敢问路在何方
第二模块 底层网络知识详解:最重要的传输层 (4讲)
第10讲 | UDP协议:因性善而简单,难免碰到“城会玩”
第11讲 | TCP协议(上):因性恶而复杂,先恶后善反轻松
第12讲 | TCP协议(下):西行必定多妖孽,恒心智慧消磨难
第13讲 | 套接字Socket:Talk is cheap, show me the code
第二模块 底层网络知识详解:最常用的应用层 (4讲)
第14讲 | HTTP协议:看个新闻原来这么麻烦
第15讲 | HTTPS协议:点外卖的过程原来这么复杂
第16讲 | 流媒体协议:如何在直播里看到美女帅哥?
第17讲 | P2P协议:我下小电影,99%急死你
第二模块 底层网络知识详解:陌生的数据中心 (6讲)
第18讲 | DNS协议:网络世界的地址簿
第19讲 | HTTPDNS:网络世界的地址簿也会指错路
第20讲 | CDN:你去小卖部取过快递么?
第21讲 | 数据中心:我是开发商,自己拿地盖别墅
第22讲 | VPN:朝中有人好做官
第23讲 | 移动网络:去巴塞罗那,手机也上不了脸书
第三模块 热门技术中的应用:云计算中的网络 (5讲)
第24讲 | 云中网络:自己拿地成本高,购买公寓更灵活
第25讲 | 软件定义网络:共享基础设施的小区物业管理办法
第26讲 | 云中的网络安全:虽然不是土豪,也需要基本安全和保障
第27讲 | 云中的网络QoS:邻居疯狂下电影,我该怎么办?
第28讲 | 云中网络的隔离GRE、VXLAN:虽然住一个小区,也要保护隐私
第三模块 热门技术中的应用:容器技术中的网络 (3讲)
第29讲 | 容器网络:来去自由的日子,不买公寓去合租
第30讲 | 容器网络之Flannel:每人一亩三分地
第31讲 | 容器网络之Calico:为高效说出善意的谎言
第三模块 热门技术中的应用:微服务相关协议 (5讲)
第32讲 | RPC协议综述:远在天边,近在眼前
第33讲 | 基于XML的SOAP协议:不要说NBA,请说美国职业篮球联赛
第34讲 | 基于JSON的RESTful接口协议:我不关心过程,请给我结果
第35讲 | 二进制类RPC协议:还是叫NBA吧,总说全称多费劲
第36讲 | 跨语言类RPC协议:交流之前,双方先来个专业术语表
第四模块 网络协议知识串讲 (4讲)
第37讲 | 知识串讲:用双十一的故事串起碎片的网络协议(上)
第38讲 | 知识串讲:用双十一的故事串起碎片的网络协议(中)
第39讲 | 知识串讲:用双十一的故事串起碎片的网络协议(下)
第40讲 | 搭建一个网络实验环境:授人以鱼不如授人以渔
答疑与加餐 (9讲)
协议专栏特别福利 | 答疑解惑第一期
协议专栏特别福利 | 答疑解惑第二期
协议专栏特别福利 | 答疑解惑第三期
协议专栏特别福利 | 答疑解惑第四期
协议专栏特别福利 | 答疑解惑第五期
加餐1 | 测一测:这些网络协议你都掌握了吗?
加餐2 | 创作故事:我是如何创作“趣谈网络协议”专栏的?
加餐3 | “趣谈网络协议”专栏食用指南
第2季回归 | 这次我们来“趣谈Linux操作系统”
结束语 (1讲)
结束语 | 放弃完美主义,执行力就是限时限量认真完成
趣谈网络协议
登录|注册

第14讲 | HTTP协议:看个新闻原来这么麻烦

刘超 2018-06-18

前面讲述完传输层,接下来开始讲应用层的协议。从哪里开始讲呢,就从咱们最常用的 HTTP 协议开始。

HTTP 协议,几乎是每个人上网用的第一个协议,同时也是很容易被人忽略的协议。

既然说看新闻,咱们就先登录 http://www.163.com

http://www.163.com 是个 URL,叫作统一资源定位符。之所以叫统一,是因为它是有格式的。HTTP 称为协议,www.163.com 是一个域名,表示互联网上的一个位置。有的 URL 会有更详细的位置标识,例如 http://www.163.com/index.html 。正是因为这个东西是统一的,所以当你把这样一个字符串输入到浏览器的框里的时候,浏览器才知道如何进行统一处理。

HTTP 请求的准备

浏览器会将 www.163.com 这个域名发送给 DNS 服务器,让它解析为 IP 地址。有关 DNS 的过程,其实非常复杂,这个在后面专门介绍 DNS 的时候,我会详细描述,这里我们先不管,反正它会被解析成为 IP 地址。那接下来是发送 HTTP 请求吗?

不是的,HTTP 是基于 TCP 协议的,当然是要先建立 TCP 连接了,怎么建立呢?还记得第 11 节讲过的三次握手吗?

目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面,默认是开启了 Keep-Alive 的,这样建立的 TCP 连接,就可以在多次请求中复用。

© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《趣谈网络协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(67)

  • 月饼
    既然quic这么牛逼了干嘛还要tcp?
    2018-06-20
    3
    50
  • 我那么圆
    http1.0的队首阻塞

    对于同一个tcp连接,所有的http1.0请求放入队列中,只有前一个请求的响应收到了,然后才能发送下一个请求。

    可见,http1.0的队首组塞发生在客户端。

    3 http1.1的队首阻塞

    对于同一个tcp连接,http1.1允许一次发送多个http1.1请求,也就是说,不必等前一个响应收到,就可以发送下一个请求,这样就解决了http1.0的客户端的队首阻塞。但是,http1.1规定,服务器端的响应的发送要根据请求被接收的顺序排队,也就是说,先接收到的请求的响应也要先发送。这样造成的问题是,如果最先收到的请求的处理时间长的话,响应生成也慢,就会阻塞已经生成了的响应的发送。也会造成队首阻塞。

    可见,http1.1的队首阻塞发生在服务器端。

    4 http2是怎样解决队首阻塞的

    http2无论在客户端还是在服务器端都不需要排队,在同一个tcp连接上,有多个stream,由各个stream发送和接收http请求,各个steam相互独立,互不阻塞。

    只要tcp没有人在用那么就可以发送已经生成的requst或者reponse的数据,在两端都不用等,从而彻底解决了http协议层面的队首阻塞问题。
    2019-01-29
    3
    41
  • 鲍勃
    我是做底层的,传输层还是基本能hold住,现在有点扛不住了😂
    2018-06-18
    2
    24
  • 云学
    http2.0的多路复用和4g协议的多harq并发类似,quick的关键改进是把Ack的含义给提纯净了,表达的含义是收到了包,而不是tcp的"期望包"
    2018-06-19
    17
  • 墨萧
    每次http都要经过TCP的三次握手四次挥手吗

    作者回复: keepalive就不用

    2018-06-18
    10
  • 起风了001
    以前一直不是很确定Keep-Alive的作用, 今天结合tcp的知识, 终于是彻底搞清楚了. 其实就是浏览器访问服务端之后, 一个http请求的底层是tcp连接, tcp连接要经过三次握手之后,开始传输数据, 而且因为http设置了keep-alive,所以单次http请求完成之后这条tcp连接并不会断开, 而是可以让下一次http请求直接使用.当然keep-alive肯定也有timeout, 超时关闭.

    作者回复: 赞

    2019-05-21
    1
    9
  • 田豪杰
    一窍不通,云里雾里
    2018-07-13
    8
  • Summer___J
    老师,目前QUIC协议的典型应用场景是什么?这个协议听上去比TCP智能,随着技术演进、这个协议已经融合到TCP里面了还是仍然是一个独立的协议?
    2018-06-28
    6
  • 传说中的风一样
    cache control部分讲错了,max–age不是这么用的

    作者回复: 这里忘了说一下客户端的cache-control机制了,一个是客户端是否本地缓存过期。这里重点强调的类似varnish缓存服务器的行为

    2019-04-23
    4
  • 花仙子
    UDP不用保持连接状态,不用建立更多socket,是不是就说服务端只能凭借客户端的源端口号来判定是客户端哪个应用发送的,是吗?

    作者回复: 是的

    2019-02-11
    4
  • skye
    “一前一后,前面 stream 2 的帧没有收到,后面 stream 1 的帧也会因此阻塞。”这个和队首阻塞的区别是啥,不太明白?

    作者回复: 一个是http层的,一个是tcp层的

    2018-06-20
    1
    4
  • pain
    怎么说呢,感觉听了跟看书效果一样的,比较晦涩。因为平时接触比较多的就是 tcp http ,结果听了感觉对实际开发好像帮助不大,因为都是一个个知识点的感觉,像准备考试。希望能结合实际应用场景,讲解。

    作者回复: 太深入就不适合听了,所以定位还是入门

    2019-01-25
    3
  • 张张张 💭
    那个keepalive不是很理解,如果是这种模式,什么时候连接断开呢,怎么判断的,比如我访问淘宝首页,有很多http请求,是每个请求独立维护一个keepalive吗
    2018-06-29
    1
    3
  • 雾满杨溪
    http和socket之间有什么关系?
    2018-06-20
    1
    3
  • 楚人
    第13和14节有些难度,需要多看多听几遍
    2018-06-18
    3
  • heliang
    http2.0 并行传输同一个请求不同stream的时候,如果“”前面 stream 2 的帧没有收到,后面 stream1也会阻塞",是阻塞在tcp重组上吗

    作者回复: 是的

    2019-04-12
    2
  • - -
    “当其中一个数据包遇到问题,TCP 连接需要等待这个包完成重传之后才能继续进行。虽然 HTTP 2.0 通过多个 stream,使得逻辑上一个 TCP 连接上的并行内容,进行多路数据的传输,然而这中间并没有关联的数据。一前一后,前面 stream 2 的帧没有收到,后面 stream 1 的帧也会因此阻塞。” 请问这一段怎么理解?感觉和前面所述“http2.0的乱序传输支持”是不是有些矛盾?

    作者回复: 两层,一个是http层,一个是tcp层

    2019-02-05
    2
  • 陆培尔
    QUIC协议自定义了连接机制、重传机制和滑动窗口协议,感觉这些都是原来tcp干的活,那为啥QUIC是属于应用层协议而不是传输层呢?应该把QUIC协议加入内核的网络栈而不是做在chrome这样的用户态应用程序里面吧

    作者回复: 基于UDP

    2019-01-16
    1
    2
  • tim
    有个问题:
    文中指出tcp采样不准确。 序列号可以发送一致的。

    但是之前讲的序列号是根据时间来增长的,除非你过去非常长的时间,不然是不可能重复的。

    这个问题不知是我理解序列号的增长策略有问题还是文中作者的推断有问题🤨

    作者回复: 是同一个序列号发送两次,也就是说同一个包发送两次

    2018-10-30
    2
  • 小辉
    获取MAC地址时,局域网内的arp 广播跟发给网关的arp广播的广播内容有什么差异吗?
    2018-07-04
    2
收起评论
67
返回
顶部