William 置顶2019-09-11【📒笔记-HTTP发展史】
+ HTTP/0.9 确立了C/S架构，域名、IP、端口。换行回车作为基本分隔符。
+ HTTP/1.0 返回码、header、多字符集、多行请求支持
+ HTTP/1.1 长连接keep-alive。分块传输chunked。方法、返回码更全面，缓存控制策略，content negotiation。
+ HTTP/2.0 头部压缩。多路复用(仍然存在线头阻塞)。二进制传输支持。服务端推送。ALPN。
+ HTTP/3.0 0RTT建连(UDP)、多路复用(无线头阻塞)。
【思考题】
1.分块传输的应用场景：分部加载请求，缩短用户首屏等待时间，提高用户体验。是一种比ajax更好的方案，能少量的请求数。
2.语义明确无歧义。
【抓包思考题】
HTTP请求和响应报文之外，很多是TCP握手报文，用于建立和断开端到端的TCP可靠连接。TCP是HTTP和HTTPS的低层协议，保证数据可靠性、完整性、有序性等。展开作者回复: 笔记部分：
优秀，说得太棒了。做一点小小的说明：文中说的客户端和服务端的概念完全是从网络和协议的角度来进行的，和我们平时提到的选择 C/S 还是 B/S 的“应用模式”有所区别。HTTP 本身和选用 C/S（Client/Server）还是 B/S（Browser/Server）并没有必然关系。也就是说，无论你使用客户端还是浏览器，都可以使用 HTTP 方式和服务端交流。
思考题部分：
1. 分块传输和 Ajax 并没有直接联系，也就是说，分块传输可以使用、也可以不使用 Ajax 来完成。Ajax 的要点是使用异步 JavaScript 的方式来请求和处理网页上的数据。因此，这个问题，你可以再想想。:) （顺便预告一下，我们在 03 篇就会介绍其中的一个使用场景）
2. 正确。当然，还有其他的原则，比如数据传输的效率，可靠性，协议本身的向后兼容性，等等等等。
抓包的问题：正确，其它的基本都是 TCP 层的报文（当然，不只有连接建立握手的报文）。 11
2019-09-14因为有墙的原因，所以需要海外节点才能telnet到google的80端口。
建议使用https://labs.play-with-docker.com ，可以一份中之内拉起一个海外linux实例。作者回复: 嗯，了解。很好的建议。
1 5
2019-09-12老师例子能不能用百度，bing之类的，谷歌国内不可用啊作者回复: 专栏几乎所有的例子都可以使用别的 HTTPS 网站来完成。这一篇里面除了 HTTP/0.9 那个小部分不能以外，其它全部都可以使用百度或者 Bing 完成。:)
4
2019-09-17思考题1：
分块传输两个特性：
1. 分块传输可以保持 HTTP 的持续链接（即 Keep-Alive）。
2. 分块传输可以让客户端在 body 信息发送完后，继续发送额外的 header 信息。
基于这两个特性，暂时想到下面两个类似的应用场景：
- 优先传输网页上最重要的内容（比如首屏内容，首屏 CSS），其他延后传输。
- 页面上内容的长度未知的场景，比如瀑布流布局。
- 可以在内容传输后，加上 Expires header，来告知内容是否已经过期。
思考题2：
暂时想到下面这些设计原则：
- 向前兼容
- 简单易用
- 可扩展
抓包：
第一次使用 Wireshark 分析抓包，感觉很有趣。
filter 的都是 TCP，而且发现大部分 TCP 都是成对出现，dest 和 src 相互交换。不知道这是不是就是文中提到的「握手」？
使用 python3 的朋友，如果发现文中的代码不好用，是因为 SimpleHTTPServer 在 3 中合并入了 http library，可以使用 http.server 替代，代码如下：
python -m http.server 8080
谢谢扩展阅读，学到之前很多不知道的知识。展开作者回复: 感谢你的回答，同时也感谢指出 Python3 下的方法。
关于你的问题，开始的部分是 TCP 的 handshake，后面还有数据传输，以及 teardown。 3- 2019-09-11思考题：
1. 当需要传输一个大文件，不能一次传完，可以使用分块传输，这里的分块传输和 UDP 中的分块传输类似吗？
2. 罗列了下，大概有几点：
1）不存在歧义，计算机最难做的事就是做选择
2）尽可能地简单
3）保证以后容易扩展
4）尽可能模块化
5）对于发送操作一定要严格，对于接收操作要有一定的容忍度
选修课堂思考题：
除了 HTTP 报文外，剩下的都是 TCP 报文，因为 TCP 是 HTTP 的下一层，其需要建立连接，并接收或者发送数据到 HTTP，有了 TCP 报文才能够更为详细地反应网络中数据的传递展开作者回复: 1. 对，“一次传不完”是其中一个应用场景。它和 TCP 或 UDP 的 packet 的概念有些像，但是他们是在不同的层次，一个是在应用层，一个是在传输层。
2. 嗯，这些都是很好的方面。
选修课堂问题：正确 1 
2019-10-17老师您好，我在使用 netcat 的过程中遇到了一个问题：
我可以通过 proxychain curl www.google.com 的方式来访问，但是下面这条命令就不行了：
proxychain nc -x 31211 www.google.com 80 < request.txt （31211 是我 socks5 的端口号）
报错是：nc: read failed (0/3): Broken pipe
网上没有查到这个怎么解决的方法，最后还是来请教一下老师。。
2019-09-27第一个坎 telnet google 时被gfw 如何破解作者回复: 你可以使用其它的 HTTPS 网站，原理是一样的。你也可以看其它的回复，有朋友给出了其它办法。
2019-09-211.1长连接keep-alive和2.0的多路复用有什么区别？
通过请求自己的后端服务，抓包发现是每次交互都要使用一个tcp连接，如果要使用http1.1的长连接功能，是后端的实现吧，请问具体应该如何实现，让后端支持长连接？作者回复: 好问题。
这两个是不一样的，keep-alive 是不关闭 TCP 连接，也就是长连接，但是在不使用管道机制的情况下，交互是单工的，即客户端必须要等前一个请求的响应返回之后，新的请求才能发过去。而在使用管道机制的情况下，请求发送可以非阻塞，但是响应返回必须依然严格按照请求的顺序。
而多路复用则是基于流的，那么在传输的时候，无论请求还是响应，只要逻辑上允许就可以传输，如果两个请求没有依赖关系可以不必等待前一个返回而直接发送，虽说用的是同一条连接。
长连接需要客户端和服务端都要支持，同时 HTTP/1.1 的 keep-alive 要打开，对于这个 TCP 连接的维护，大多数 web 服务器都支持。
2019-09-20四火老师，有个小疑问，长连接保持多久，什么时候结束长链接，进行下一次三次握手作者回复: 这个协议里面并未规定具体时间：在没有数据传输的时候，保持一定的时间，之后服务端和客户端都可以主动结束长连接。
2019-09-13我可以access google，但是使用telnet www.google.com 80后cmd中啥也没有，按ctrl+c退出后cmd中看到出现以下错误：
HTTP/1.0 400 Bad Request
Content-Length: 54
Content-Type: text/html; charset=UTF-8
Date: Thu, 12 Sep 2019 18:28:18 GMT
<html><title>Error 400 (Bad Request)!!1</title></html>
这是google不支持telnet了吗？然后我试了下telnet www.example.com 80，同样cmd中啥也没有，按ctrl+c退出后出现以下信息说unimplemented：
HTTP/1.0 501 Not Implemented
Content-Type: text/html
Content-Length: 357
Connection: close
Date: Thu, 12 Sep 2019 18:30:31 GMT
Server: ECSF (bsa/EB24)
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>501 - Not Implemented</title>
</head>
<body>
<h1>501 - Not Implemented</h1>
</body>
</html>
Connection to host lost.
然后装了netcat，在安装目录下写好课件里面的request.txt，然后运行nc后在Cmd line后面输入 www.google.com 80 < ~request.txt或者www.example.com 80 < ~request.txt，运行后说 invalid port < ~request.txt，请问老师为什么port会是invalid？
上面这些错误是我运行有误还是windows的问题？展开作者回复: 关于 Google 那个，不清楚你的网络环境是否有特别的限制，否则应该是能够使用 telnet 的。你可以试试别的服务，看看telnet是否能访问。另外，telnet 只是建立了 tcp 连接，你需要发送消息才能得到响应。比如，在我的Mac上如下：telnet www.google.com 80
Trying 2607:f8b0:400a:809::2004...
Connected to www.google.com.
Escape character is '^]'.
GET /
...
netcat 的话，那个例子不是使用交互模式，而是直接运行：netcat www.google.com 80 < 文件路径
2019-09-12在mac终端bash中，直接用python -m SimpleHTTPServer 8080 提示语法有错，不知道什么原因作者回复: 你要是能贴出问题来大家可能能一起看一下。另外，你看看是不是这个原因：由于某些原因我的文章中没有使用 python 3，如果你用的是 python3，命令是 python3 -m http.server 8080 （当然，如果你默认的 python 版本就是 3.xx 的，那么使用 python 替换 python3）
当然，你也完全可以抓访问其他网站的包，tcpdump 的命令需要稍微改一改（不是抓本机的 loopback 的包了）。
2019-09-12刚看到标题以为是一篇枯燥的介绍http协议历史的文章，看了以后发现这种和实践相结合的内容很有意思，这个专栏应该会有很多收获。感谢四火老师。另外其它学员的留言也很有启发，希望自己以后也能有高质量都留言。作者回复: 感谢你的认可！
2019-09-12问题一：在线视频播放，先传输完整视频的部分包，让视频缓冲播放，提升用户体验。当然，流媒体是不走http协议的，走http的类似场景都是比较适合的。
问题二：如果是应用层协议，那报文的格式化和解析、请求应答的规则是重点。通用简明的报文格式易于格式化和解析，适合粒度的应答码便于标示请求状态。作者回复: 其实流媒体有使用 HTTP 也有不使用 HTTP 的，其它方面理解正确。对于协议的问题，理解挺不错的，当然，这两个都 是开放的问题，你也可以看看其他人的回答 :)
2019-09-11抓包的应用场景都有哪些呀，老师作者回复: 在和网络、Web 接口、性能等问题打交道的时候，很常用。
2019-09-11完了，这课不好学啊，好多不懂，看着一头雾水，缺少必要的知识去联系起来，工具还得自己去查查学起来，还要阅读英文文章。。。。。作者回复: 你好 xcoder，别害怕，每个人不同领域的知识储备都不同。你要是能具体谈谈那些不懂，我可以想想办法帮你
- 2019-09-11老师，请问netcat在mac电脑上怎么安装呢？
作者回复: 你可以安装 Homebrew https://brew.sh/ 这个包管理工具，这样以后这些工具大多可以用它来安装，包括 netcat：
brew install netcat 
2019-09-11可能因为职业的特性吧：网络协议的设计基本都是由专业的网络工程师去做的；老师今天的第二个问题其实同样希望老师能够再后续课程做个思路的讲解吧。
今天课程中的tcpdump和wireshark之前都有使用过和强化过：课程中就略过了。
课后习题做个简单解答吧：第二个问题还是希望老师后面用个篇幅或者在某节课中讲解一下核心思路吧，麻烦老师了，给老师添加工作量了。
1.Http特性的使用场景：简单的说其实主要是解决了人与机器通过使用万维网的通信，实现人机交互吧，解决 WWW 信息交互必须面对的需求。
（1）http1.1
1）可扩展性：巨大的用户群体，超长的寿命
2）分布式系统下的 Hypermedia：大粒度数据的网络传输
3）Internet 规模
（2）http 2.0在此基础上解决了：多路复用和服务器消息推送.
2.设计过程中的遵循原则：这块算是通过工作中的交互简述吧；
1）内外网的隔离：根据功能划分网段
2）根据需求选择合适的网络设计模型吧：星形或者、、、
网络的工具可能工作中使用偏多点：设计实在是偏弱，希望后面课程能够得到老师的提点和教导；谢谢老师今天的分享。展开作者回复: 既然你特别说到第二个问题，你的回答中“内外网的隔离”其实是它下层的协议，例如第三层的网络层中的 IP 协议关心的，而不是第七层应用层的 HTTP 所关心的。建议你阅读以下扩展阅读 OSI 相关的内容。
设计方面，本专栏中不会详细解读协议设计，但会有很多应用层协议的使用，以及特别强化 Web 接口的设计的介绍。:)
2019-09-11赞，这是我订阅的课程里最“网络协议”式的课程了。
为什么呢？
定义网络协议就要像老师今天的课一样：
1、层次分明。适应于不同水平的人阅读，就像网络协议一样适应多种应用场景。
2、扩展性强。文后给出扩展阅读，可以根据自己的需要进行不同程度的延展。展开作者回复: 感谢。后面的文章也会尽量保持层次，每篇都有扩展阅读，争取让不同的人都有收获。当然，这篇是第一篇相对来说比较简单。
2019-09-11最近正好要做一个简单的私有协议实现从server下载包列表和具体的包文件，打算用http get，对http协议知之甚少，也没抓过包，这课来的太及时了。作者回复: 加油。特别是抓包这项技能，还是很实用的。当然，我只是给了个最简单例子。专栏后面我们还会使用抓包来分析问题。