网络系统 -- IT技术博客大学习 -- 共学习共进步！

最近有个需求是让某个服务器能够响应一整个网段的请求，研究了一下，发现比想象的容易。

NFC 用例大多与公司使用蓝牙的用例是分开的，对于少有的可以选择的重叠，相对的优势和劣势显而易见。NFC 距离很短、价格便宜、可即时连接以及数据转换率较低。BLE 的工作距离更远、传输速率更高，成本也更高，连接时还需要一点时间来进行“握手”。

• 内网穿透神器frp

在许多情况下，我们希望把内部的服务暴露到外网来使用，比如说： 1、在公司内网开发程序，要和微信联调； 2、想要随时随地登录家里的树莓派，使用上面的服务在这些情况下，我们就会很迫切的希望有一个内网穿透服务，帮我们把内部的端口，暴露到外网来。

• 直播/点播中HTTP Live Streaming(HLS)协议的简介与使用

HTTP Live Streaming（缩写是 HLS ）是一个由苹果公司提出的基于 HTTP 的流媒体网络传输协议。是苹果公司 QuickTime X 和 iPhone 软件系统的一部分。它的工作原理是把整个流分成一个个小的基于 HTTP 的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的 extended M3U (m3u8)playlist 文件，用于寻找可用的媒体流。

• 你不在意的HTTPS证书吊销机制

《长安十二时辰》里的望楼系统由“传递系统+加密系统”组成，靖安司作为一个军事级别的机构，信息传递绝对是多重加密的。通传陆三是暗桩，导致信息传递系统泄密，这些问题如果发声在HTTPS通讯中，丢了密钥，会怎样？是不是也没法防范这个私钥被利用了？

• 一图看懂HTTP缓存控制/浏览器缓存控制

从网上看到一张图，觉着挺不错的，拿来和大家分享。但后来发现，这张图一开始的部分存在错误，所以还是整理下缓存控制的内容。浏览器的缓存，主要分为两种：强缓存 200 (from memory cache)和200 (from disk cache) 协商缓存 304 (Not Modified)

• Http/2知识图谱

HTTP/2和HTTP/1.x之间存在很大的差异，但文中优化规则是仍然是通用的。 HTTP/2不适合采取的规则，可参考文中知识图谱中的反模式。

• 使用DNSPOD的API实现动态域名

使用DNSPOD的API实现动态域名方法介绍。

• 重要的事情说三遍：ARQ协议

这是一个能应用在一个不可描述的场景中的协议。 ARQ 是一种在数据传输过程中，错误控制的策略，保证了数据的完整性和顺序性。核心目的是在不可靠的网络上实现可靠的数据传输。比如，在短波无线电传输，GSM 网络，电报等领域都有很广泛的应用。在当今因为各种原因导致的复杂互联网环境上，某些点对点传输的服务，也变得不那么可靠，可以考虑引入 ARQ 策略。在服务器端开发方面，ARQ 的思想，也可以给我们在服务实现时候，很多的启发。此外，这种策略的学习和理解，也是理解更复杂的网络协议的基础。

• TCP 滑动窗口与窗口缩放因子(Window Scaling)

说道TCP滑动窗口协议，相信大家都很熟悉，但是说道 Window Scaling参数或许知道的和用过的人却不多，本文我们来谈谈Window Scaling的由来。

• 流量引导：网络世界的负载均衡解密

大型的多站点互联网系统，包括内容分发网络（CDN）和云服务提供商，用一些方法来均衡来访的流量。这篇文章我们讲一下常见的流量均衡设计，包括它们的技术手段和利弊权衡。早期的云计算服务提供商，可以提供单一一台客户 Web 服务器，分配一个 IP 地址，然后用一个便于人读的域名配置一个 DNS 记录指向这个 IP 地址，再将 IP 地址通过边界网关协议（BGP）宣告出去，BGP 是在不同网络之间交换路由信息的标准方式。这本身并不是负载均衡，但是能在冗余的多条网络路径中进行流量分发，而且可以利用网络技术让流量绕过不可用的网络，从而提高了可用性（也引起了非对称路由的现象）。

• Windows 下重定向当前进程的 stdout 到网络连接

前段时间碰到一个需求，想把当前进程的标准输出重定向到一个 tcp 连接上。如果依照 posix 标准，调用一下 dup2 这个 api 就能搞定，但是 windows 并不是基于 posix 标准的操作系统，所以做起来要麻烦的多。我在 stackoverflow 和 msdn 上找了一番，没有看到什么靠谱的做法，所以自己折腾了一天。这里的难点在于：windows 上虽然有 _dup2 来模拟 posix 的 api dup2 ，但 fd 在 windows 上并不是内核对象， HANDLE 才是。fd 是在 runtime 层模拟出来的东西。msdn 上引用最多的一篇是：Creating a Child Process with Redirected Input and Output ，做的事情是创建一个子进程，然后重定向标准输入输出。

• 关于TCP可靠性的一点思考，借此浅谈应用层协议设计

本文主要讨论如何设计一个可靠的RPC协议。TCP是可靠的传输协议，不会丢包，不会乱序，这是课本上讲述了无数遍的道理。基于TCP的传输理论上来说都是可靠的，但是实际这也得看场景。当我做网络游戏的时候也是一直把它当一个可靠的传输协议来用，从没考虑过TCP丢包的问题。直到当我面临像网络存储、机器学习这样领域时，我发现TCP变得“不可靠”了。

• 一次连接超时问题排查的历程

我们有一个 java 应用，启动的时候要初始化连接池，在连接一堆 sharding 过的 DB 时，经常会有一部分连接超时失败的，集中在一两台后端机器上，但每次失败的后端服务器却又不固定，也并不是每次启动都能遇到。超时时间设为了 50ms，看起来有点短但是对局域网，和压力并不算大的 DB 来说，这个时间已经长得匪夷所思了。后来尝试调大成 100ms，还是有失败的。但是如果启动成功后，却没再记录到过连接超时的情况。

• Spark性能优化——和shuffle搏斗

Spark的性能优化有一些特殊的地方，比如实时性一般不在考虑范围之内，通常我们用Spark来处理的数据，都是要求异步得到结果的数据；再比如数据量一般都很大，要不然也没有必要在集群上操纵这么一个大家伙，等等。事实上，我们都知道没有银弹，但是每一种性能优化场景都有一些特定的“大boss”，通常抓住和解决大boss以后，能解决其中一大部分问题。比如对于portal来说，是页面静态化，对于web service来说，是高并发（当然，这两种可以说并不确切，这只是针对我参与的项目总结的经验而已），而对于Spark来说，这个大boss就是shuffle。

• 三种解密 HTTPS 流量的方法介绍

Web 安全是一项系统工程，任何细微疏忽都可能导致整个安全壁垒土崩瓦解。拿 HTTPS 来说，它的「内容加密、数据完整性、身份认证」三大安全保证，也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响。很多同学认为只要访问的网站地址前有一把小绿锁就绝对安全，其实不然。本文通过介绍三种最常规的 HTTPS 流量解密方法及原理，浅谈一下 HTTPS 的安全风险。

• 移动端测试的代理服务器搭建

移动设备想要访问位于局域网中的某个特定设备上搭建的服务，需要通过代理服务器来实现，针对不同操作系统搭建代理服务器有不同的软件，如果系统是 OS X 的话，可以使用 Charles，对于 Windows，可以使用大名鼎鼎的 Fiddler ，可视化软件的使用这里不详述，本文重点讲述在 Unix/Linux 上使用 Squid 来搭建代理服务器。

• 微信收费事件背后被广泛忽略的技术细节

作为一个横跨通信与互联网两大行业的从业者，前四年的核心网经验和后五年的互联网经验让我不得不感慨一个非常遗憾的现实：通信与互联网两大行业本来可以有珠联璧合的技术协同，为移动互联网提供近乎零耗电零流量的PUSH机制，但由于两个行业之间长期以来的价值观隔阂和互防心态，导致如今的手机PUSH技术不仅为用户增加了显著的电量消耗，还对移动运营商的基础设施造成了完全不必要的信令压力。微信与运营商的纷争正是这种冲突集中爆发的结果。

• 移动端网络优化

介绍下针对移动端的网络优化，不限于 Android，同样适用于 iOS 和 H5。

• 可靠 UDP 传输

本文分三个部分：一，什么时候有可能采用 UDP 通讯而不是用 TCP 更好；二，一个可靠的 UDP 通讯模块的 API 接口该如何设计；三，一个简单的实现。