如何判断流量属于HTTP还是TCP？如何为应用选择GCP对应负载均衡器？

很多新手选GCP负载均衡的时候，容易被“TCP”“HTTP”的协议概念绕晕，其实根本不需要死背OSI七层模型，对着实际场景判断就行：
核心判断锚点：先看你的应用是跑通用HTTP/HTTPS标准协议，还是跑自定义非HTTP的TCP私有协议

适合选HTTP(S)负载均衡的典型场景 #

只要满足下面任意一类，优先选HTTP(S) LB，性价比和功能适配性远高于TCP类LB：

• 应用访问时直接通过http://或https://开头的地址打开：包括普通企业网站、移动端App的后端API、小程序服务、Web管理控制台、静态资源站点，不管后端是用什么语言开发的，只要走标准HTTP/HTTPS协议传输，全适配
• 需要基于应用内容做流量分流：比如把不同域名、不同URL路径的请求路由到不同后端服务（比如your.com/api走业务服务集群、your.com/static走对象存储、blog.your.com走独立的博客服务），这种细粒度的内容级路由是HTTP(S) LB的原生能力，TCP类LB只能基于IP、端口做转发，根本实现不了
• 需要利用应用层能力：比如做基于Cookie的会话保持、给静态资源做边缘缓存、对接Web应用防火墙拦截恶意请求、按照请求头识别用户身份做流量控制，这些能力都是HTTP(S) LB内置的

必须选TCP/SSL代理负载均衡的典型场景 #

只要满足下面任意一类，就别硬套HTTP(S) LB，选TCP/SSL代理就行：

• 应用根本不跑标准HTTP协议：包括自建的公开数据库（MySQL、PostgreSQL、Redis）、自研即时通讯长连接服务、游戏对战服务、走私有自定义协议的工业设备接入端，这类流量的内容是通用HTTP解析器无法识别的，HTTP(S) LB根本没法正常转发
• 需要暴露非80/443端口的TCP公开服务：比如自定义端口的远程访问服务、FTP服务，HTTP(S) LB天生只处理HTTP/HTTPS协议的流量，没法转发这类非HTTP的TCP包
• 需要全链路SSL透传：也就是要求代理层不解密加密流量，直接把加密的TCP请求原封不动转给后端服务，由后端自己完成证书校验和解密——这种场景下TCP/SSL代理支持端到端的加密透传，而HTTP(S) LB必须在代理层解密流量才能做路由，满足不了隐私隔离的要求

最容易踩的认知误区：不要因为“HTTP是跑在TCP协议之上的”就觉得所有HTTP流量都要选TCP类LB。HTTP(S) LB是专门针对HTTP流量优化过的产品，不管是转发性能、功能丰富度、运维成本，都比用TCP类LB转发HTTP流量好得多，没必要舍近求远。

10秒自检流程 #

1. 打开应用的公开访问地址，确认浏览器地址栏是不是http:///https://开头
   • 是：直接选HTTP(S)负载均衡
   • 不是：进入下一步判断
2. 确认应用的传输协议是不是自定义的非HTTP规范的TCP私有协议（比如数据库、即时通讯、游戏长连接）
   • 是：直接选TCP/SSL代理负载均衡
   • 不是：和开发团队确认应用协议栈，不要盲目选型

内容的提问来源于stack exchange，提问作者Ram