答:HTTP 1.0协议(RFC1945)是在1996年5月发布的,其中文名“超文本传输协议”估计大约也是在1996年左右诞生的。从此以后,这个名称就被固定了下来,一直沿用到今天。 非常遗憾,这是一个错误的翻译,而且错误的性质很严重。具体来说,就是将“Hypertext Transfer Protocol”其中的“transfer”翻译错了。不应该将“transfer”翻译为“传输”,而应该翻译为“转移”或者“传递”。“传输”的英文单词应该是“transport”,而不是“transfer”。其实如果最初的译者确实曾经认真读过一些互联网协议,例如HTTP协议、FTP协议等等,就会很容易地发现,在这些协议中,“transfer”和“transport”的含义有明显的区别,根本无法混用。虽然IETF的RFC在格式上比ITU-T的那些规范要自由地多,但是RFC的作者都是非常严谨的,在术语的使用上面很少出现因混用导致的歧义。 在IETF的RFC中,“transport”(传输)的含义是指:从端到端(例如从ip1:port1到ip2:port2)可靠地搬运比特,也就是TCP/IP协议栈中的第3层传输层(transport layer)协议所做的那些事情。将“transport”翻译为“传输”,100%正确! 而“transfer”的含义是:通过在客户端-服务器端之间转移一些带有操作语义的操作原语,来执行某种操作。“transfer”是TCP/IP协议栈中的第4层应用层的概念,而不是第3层传输层的概念。“transfer”所转移的是带有明确操作语义的操作原语,而不是没有操作语义的比特流。 不仅仅非专业的翻译者很难理解“transfer”和“transport”的区别,很多经验丰富的Web开发者也常常混淆两者的区别。即使在母语为英语的国家,同样也存在着很多混淆。但是理解两者之间的区别,是理解HTTP协议本质的关键。为了澄清这个问题,HTTP 1.1协议的主要作者Roy Fielding在其2000年发表的博士论文《Architectural Styles and the Design of Network-based Software Architectures》(中文版名为《架构风格与基于网络的软件架构设计》)的6.5.3小节中专门强调:HTTP并不是一种传输协议,其具体内容参见下一个问题。

综上所述,HTTP协议名称中的“transfer”可以肯定是与“传输”没什么关系的。“传输”这件事情,传输层协议TCP/UDP已经做的很好了,不需要HTTP再来越俎代疱。既然“transfer”与“transport”含义有明显区别,而“transport”又被正确地翻译为“传输”,那么将“transfer”也翻译为“传输”,必然会带来很大的误导。从实事求是的角度,我们作为专业的Web开发者,不应该任由“超文本传输协议”这个名词以讹传讹继续流传下去,贻害广大初学者。

那么将“transfer”翻译为什么更好呢?我在翻译Fielding博士论文时,对于这个问题曾经纠结了很长时间。在中文之中,将“transfer”翻译为“转移”或者“传递”,都比翻译为“传输”要好。我最后选择了“转移”,而没有选择“传递”,主要原因是“传递”与“传输”仅有一字之差,仍然会让不求甚解的开发者产生误解,误以为“传递”与“传输”完全是相同的含义。

于是,我在Fielding博士论文中文版和《REST实战》中文版中,都将HTTP翻译为“超文本转移协议”,将REST翻译为“表述性状态转移”。在大多数地方,都将transfer统一翻译为“转移”。当然,如果你真的理解了“transfer”和“transport”之间的区别,将HTTP翻译为“超文本传递协议”,将REST翻译为“表述性状态传递”都是可以的。

具体到HTTP协议,“transfer”代表的含义是:通过在客户端-服务器端之间转移代表资源当前状态的资源表述,来对服务器端的资源执行某种操作。这既是缩写词HTTP中“transfer”的含义,也是缩写词REST中“transfer”的含义。