DoNews6月4日消息（記者費倩文）6月4日，今日頭條發(fā)布《“騰訊公司不正當競爭行為”的事實與說明》文章。文章中稱，從今年3月起，抖音、火山小視頻在分享到微信和QQ中的時候，會出現(xiàn)屏蔽、僅自己可見等無法正常分享的情況。在多次封禁行為中，頭條方認為這是不公正競爭，而騰訊方以技術、內(nèi)容審核等原因回應封禁。雖然大部分內(nèi)容在封禁之后都已恢復，但錯過了傳播最佳時間。

今日頭條希望能恢復到正常的商業(yè)競爭范疇，騰訊停止尋找各類借口進行封殺以及對頭條進行污名化。

事件回顧：

5月16日，西瓜視頻被騰訊安全管家提示為欺詐網(wǎng)站，稱其域名下有超過80%的鏈接存在違法賭博內(nèi)容。隨后頭條回應稱其涉嫌造謠誹謗。

5月17日，抖音起訴騰訊平臺，稱其平臺存在《抖音，請放過孩子》等抹黑抖音的文章，騰訊在未經(jīng)審核的情況下，允許該文章傳播，侵害了抖音的合法權益，要求賠償100萬元，并道歉。

5月22日，抖音發(fā)文質疑騰訊封殺其“正能量”短視頻，文中列舉了多項其“正能量”視頻被封禁的例子，同時稱騰訊平臺存在違禁內(nèi)容未被封禁。

5月30日，今日頭條全網(wǎng)推送標題為《新華社:要多少文件騰訊才肯收手》的文章，成為沖突的導火索。之后頭條回應稱該文章屬跟推百度百家號。

6月1日，騰訊通過官方微信公眾號發(fā)布聲明，稱今日頭條和抖音詆毀騰訊公司，并已向北京市海淀區(qū)人民法院正式起訴，只索賠人民幣1元，但要求上述兩家公司在自有新聞媒體平臺全量推送公開道歉。而聲明最后提到，將暫停與上述兩家的相關合作，意味著如果頭條系公司不給予騰訊合理的回應，騰訊與“今日頭條”及“抖音”之前由于鏈接分享造成的矛盾也將合情合理。

6月2日，頭條回應騰訊稱，“已經(jīng)對騰訊的不正當競爭行為提出訴訟”，要求騰訊公司立即停止一切不正當競爭的行為，公開賠禮道歉，同時賠償今日頭條公司共計9000萬元人民幣的經(jīng)濟損失。（完）

以下為聲明全文：

騰訊是國內(nèi)最大的互聯(lián)網(wǎng)公司，國內(nèi)任何一家公司都不愿、也不敢與騰訊為敵。自今年3月以來，騰訊公司先后找了諸多借口，如產(chǎn)品bug、閾值等對頭條系產(chǎn)品進行封禁，甚至以監(jiān)管名義以及動用其旗下安全軟件產(chǎn)品，對頭條系產(chǎn)品進行封禁，在封禁的同時還進行“污名化”，以達到其有“合理”理由進行不正當競爭的目的。在此情況下，我們不得不將騰訊公司的“不正當競爭行為”事實公布如下：

一、尋找各類借口對頭條系旗下產(chǎn)品進行封禁

1、3月8日，抖音、火山鏈接分享到朋友圈有可能僅為自己可見。騰訊對外稱，為避免鏈接刷屏影響朋友圈閱讀體驗，微信對朋友圈內(nèi)鏈接的傳播設有防刷屏限制；以天為計算單位，若鏈接在朋友圈分享次數(shù)觸發(fā)當日上限，將自動被屏蔽處理，次日可恢復正常。

2、3月25日，抖音分享到QQ空間僅為自己可見。騰訊對外稱，由于安全系統(tǒng)誤打擊，部分空間分享受到短暫的影響。目前已經(jīng)恢復正常。

3、4月11日開始至今，西瓜、抖音、火山分享到微信、QQ鏈接不能播放。騰訊理由：互聯(lián)網(wǎng)短視頻整治期間，暫停短視頻APP外鏈直接播放功能，并稱會一視同仁。但事實是，其新推出的下飯視頻仍可以在微信中正常分享播放。

4、5月15日，抖音個人頁圖片被朋友圈屏蔽。騰訊給出的理由是，部分APP內(nèi)容分享到微信朋友圈無法正常查看，現(xiàn)已修復。

5、5月16日，西瓜視頻網(wǎng)站被騰訊電腦管家標記為不安全網(wǎng)站。騰訊給出的理由是，因為監(jiān)測到域名m.365yg.com含有大量以“騰訊分分彩”為名義的違法賭博內(nèi)容，并通過互聯(lián)網(wǎng)渠道大規(guī)模傳播（該域名傳播的URL惡意網(wǎng)址的比例超高，超過80%）

5月25日，今日頭條發(fā)文并舉例，“傳播惡意網(wǎng)址比例超80%“說法純屬造謠，騰訊平臺也有大量違法賭博內(nèi)容。騰訊理由：騰訊平臺雖有違法賭博內(nèi)容，但量少不會觸發(fā)報警。但騰訊電腦管家對于騰訊系產(chǎn)品存在“分分彩”內(nèi)容的鏈接，卻標注為安全。

6、5月18日，抖音“第一屆文物戲精大賽”H5被微信直接封殺。騰訊理由是，抖音H5因存在誘導分享行為（但所謂“誘導分享”鏈接去掉后仍被“自見”）

7、5月25日，騰訊旗下QQ空間PC端分享今日頭條文章鏈接（域名www.toutiao.com）時，無法正常顯示。彈窗提示稱：“互聯(lián)網(wǎng)短視頻整治期間，平臺將統(tǒng)一暫停直接播放。如需觀看，仍可復制網(wǎng)址使用瀏覽器播放。”但鏈接正文實際并非短視頻，而是文字內(nèi)容。騰訊給出回復：經(jīng)排查，該體驗現(xiàn)一切正常。這個回復，雖然沒有撒謊，卻極大的誤導用戶和公眾。

8、此外，微信甚至一度發(fā)布公告，稱“外部鏈接不得在未取得信息網(wǎng)絡傳播視聽節(jié)目許可等法定證照的情況下，以任何形式傳播含有視聽節(jié)目的內(nèi)容”。最后，應開發(fā)者反饋意見，刪除此項“禁令”。

二、微信出現(xiàn)大量惡意攻擊抖音的內(nèi)容

大量抹黑文章將用戶在其他平臺上傳，帶有明顯的“騰訊視頻”等水印，和抖音明顯無關的傷害兒童的視頻素材（甚至有些視頻出現(xiàn)在抖音上線之前），作為抖音誤導小孩的證據(jù)，更冠以“人命”等字眼，利用讀者恐懼的情緒，以假亂真，嫁禍抖音。

此外，還有文章將“手槍鉆吃玉米”、“鞭炮炸襠”等明顯不屬于抖音的負面內(nèi)容，在文章中強加給抖音，進行聲討、傳播。上述類型的文章自3月以來至今，在微信平臺上惡意刊載流傳，合計數(shù)量超過數(shù)千條，對于抖音的產(chǎn)品聲譽造成了重大影響。

部分抹黑文章舉例如下：《抖音，請放過孩子》、《抖音正毀掉我們的下一代》、《抖音，請放過祖國的花朵吧》、《抖音是如何毀掉我們的》、《我們?yōu)槭裁磩衲阈遁d抖音》……

三、鑒于以上事實情況，我公司不得不就”騰訊不正當競爭行為“向法院提出訴訟。

案件一、騰訊QQ和QQ空間是中國互聯(lián)網(wǎng)行業(yè)最大的社交平臺之一，每天有數(shù)億用戶使用，具有極大的影響力和控制力。

當頭條用戶通過QQ空間分享、發(fā)布頭條網(wǎng)頁的文章鏈接時，會被提示“互聯(lián)網(wǎng)短視頻整治期間，平臺將統(tǒng)一暫停直接播放。如需觀看，仍可復制網(wǎng)址使用瀏覽器播放?！钡膶嶋H并非短視頻，而是文章內(nèi)容。

QQ空間事實上通過自身行業(yè)優(yōu)勢資源和地位，對頭條鏈接進行了攔截、屏蔽，妨礙了用戶正常使用頭條的服務。

此外，QQ空間虛構事實，對用戶進行虛假提示的行為，嚴重貶損和降低了我們的商業(yè)信譽和產(chǎn)品信譽，給我們造成了極其不良的社會影響和重大經(jīng)濟損失。這顯然屬于不正當競爭。

案件二、安全軟件產(chǎn)品和服務已經(jīng)成為互聯(lián)網(wǎng)的基礎服務之一，利用安全軟件進行商業(yè)競爭，是典型的不正當競爭行為。

5月16日，西瓜視頻被騰訊安全管家提示為欺詐網(wǎng)站。此后又兩次發(fā)布回應稱其監(jiān)測到的西瓜視頻域名下有超過80%的鏈接（騰訊分分彩內(nèi)容）存在違法賭博內(nèi)容。這款安全軟件已經(jīng)涉嫌造謠誹謗。對我們的品牌造成了嚴重的損害。我們被迫澄清以正視聽。

此外，我們列舉過騰訊相關產(chǎn)品，包括天天快報、QQ空間、QQ看點、QQ群，甚至微信公眾號上，都存在大量騰訊分分彩內(nèi)容。甚至，騰訊系產(chǎn)品中含有“騰訊分分彩”相關內(nèi)容的鏈接，是被騰訊管家認證為安全鏈接的。

就是說，在騰訊電腦管家看來，同樣的內(nèi)容在騰訊產(chǎn)品上就是安全的，在西瓜視頻平臺上就是不安全，甚至非法的。

這些都可以證明，騰訊管家實際上是在借安全之名進行不正當競爭。

四、說明如下：

1、微信和QQ是國內(nèi)最大社交平臺，活躍用戶已經(jīng)達以10億以上，屬于互聯(lián)網(wǎng)基礎設施，類似水電燃氣和電信運營商，具有強大的市場支配地位。這種社會支配地位，不應該被濫用到市場競爭中。

2、在此之前，頭條與騰訊一直保持良好的溝通與競合關系。從今年3月份，微信開始找各類借口對頭條產(chǎn)品進行封殺，這是兩家公司出現(xiàn)糾紛的開始。我們希望能恢復到正常的商業(yè)競爭范疇，騰訊停止尋找各類借口進行封殺以及對頭條進行污名化。

3、騰訊這種行為每天都會影響上千萬用戶進行分享通信，對此，我們不得不向公眾和媒體告知真實情況。這種“反抗”行為，在騰訊強大的社會影響力之下，在微信平臺上被騰訊和部分自媒體人冠以“戲精”“碰瓷”。騰訊可以對你的產(chǎn)品進行封殺，但你不能把這事說出去，只要說出去就是“戲精”“碰瓷”。對騰訊這種強大的社會影響力，我們深感無奈和憂慮。

隨著互聯(lián)網(wǎng)的發(fā)展，越來越多的業(yè)務不僅僅由單一節(jié)點（或是單一語言）就可承載，而是趨向多語言分布式協(xié)同開發(fā)（如接入層由Node.js完成，邏輯（數(shù)據(jù)）層由C++/GO/Python實現(xiàn)）并由此組成大型異構系統(tǒng)。

我們（現(xiàn)SuperTeam）基于 Tars 體系研發(fā)出 Tars.js 以便用戶在不改變異構系統(tǒng)整體架構的情況下快速搭建（遷移）Node.js服務，并可非常方便的將原來的單一服務拆分為多個（邏輯）子服務。

Tars.js在騰訊內(nèi)部經(jīng)過5年多的沉淀與迭代（Node.js@0.10版本即提供支持），廣泛運用于騰訊QQ瀏覽器、騰訊桌面瀏覽器、騰訊地圖、應用寶、騰訊手機管家、互聯(lián)網(wǎng)+、騰訊醫(yī)療、騰訊覓影、保險、彩票等幾十個重要業(yè)務中，日承擔了上百億流量。

Tars.js包含下述特性：

l 100%由JavaScript編寫，不包含任何C/C++代碼。

l 多進程負載均衡與管理。

l 代碼異常監(jiān)控與重啟。

l 服務日志搜集與處理。

l HTTP(s)服務監(jiān)控與用量自動上報，并支持用戶自定義維度上報（PP監(jiān)控）。

l 符合 Tars(IDL)規(guī)范的編解碼模塊。

l 支持 TarsRPC調(diào)用與染色（模調(diào)自動上報）。

l 支持在線發(fā)送管理命令、拉取服務配置。

l 獨創(chuàng) LongStackTrace?異常跟蹤機制。

l …… 更多特性可訪問 @tars/node-agent 了解

設計理念：

?A．高自由度：

l 兼容所有（≥0.10）官方Node.js版本。

l 對 Node.js源碼無侵入無修改。

l 底層對上層完全透明，支持各種上層框架，無需變更。

也就是說：

您可以使用任何您熟悉的框架（如 Express.js/Koa.js等，包括但不僅限于Web框架），也無需對框架進行任何修改（無需引入任何中間件）。即可通過Tars.js運行，享受平臺提供的各種監(jiān)控與管理特性。

與此同時，Tars.js所提供的模塊，也可以根據(jù)您的需求引入（如未使用到則可不引入）。

?B．高性能：

Tars.js為高性能與大并發(fā)量而設計，使用了大量的前端（V8）優(yōu)化技巧（如FlattenString/FastProperties等）盡量降低所提供的能力對于業(yè)務性能的影響。

經(jīng)過我們測試（WebServer），默認的旁路上報與監(jiān)控對服務性能的影響≤5%，常用模塊（RPC、日志等）性能位于業(yè)界前列。

?C．差異化：

Tars.js根據(jù)不同的業(yè)務類型提供差異化運營方案：

l 高流量業(yè)務：盡力降低框架對業(yè)務性能的影響。

l 低流量業(yè)務：充分利用硬件資源提升開發(fā)體驗。

HelloWorld

我們來看Node.js官網(wǎng)的 例子 (如下)，無需任何變更，直接通過Tars.js進行部署，它會擁有哪些特性？

? 進程管理

默認基于 cluster 模塊進行負載均衡，進程數(shù)可以配置為1~max（CPU核心數(shù)）、還可配置為auto（物理核心數(shù)相同）以減小內(nèi)存壓力提升“性價比”。

與此同時，進程僵死檢測也會同時啟動，實時監(jiān)控業(yè)務進程。

?案例說明

某服務在論壇UBB代碼轉HTML時，使用未優(yōu)化的正則表達式進行XSS攻擊過濾，但由于用戶發(fā)帖時圖片采用BASE64編碼，導致正則表達式計算時間過長，CPU使用率飆漲到100%：

開啟僵死檢測后，Tars.js監(jiān)控到業(yè)務進程僵死時，自動重啟業(yè)務進程，從而縮短了業(yè)務無響應時間：

Tars.js雖然無法解決業(yè)務代碼的問題（BUG），但會盡最大努力保證業(yè)務的可用性。

? 服務監(jiān)控

以服務名、接口名（URL-PATH節(jié)）為緯度，統(tǒng)計總流量、平均耗時、超時率、異常率：

其中返回碼大于400（可配置）作為異常進行上報。

?監(jiān)控說明

Web服務一般由靜態(tài)與動態(tài)資源（接口）組成，由于靜態(tài)資源（本地文件）的請求耗時遠低于動態(tài)資源（業(yè)務邏輯），請求量往往又很高，拉低了服務整體耗時。

基于此，Tars.js將請求URL中的PATH節(jié)作為接口，每個接口均可查看其總流量、平均耗時、異常率，便于用戶全面了解服務性能。

? 特性監(jiān)控

無論您服務的類型是什么，總是會上報下述特性，便于回溯問題與評估性能：

l memUsage：內(nèi)存用量，將會上報rss、heapUsed、heapTotal這三個用量（單位為字節(jié)）

l cpuUsage：CPU用量，將會上報CPU使用率，數(shù)據(jù)匯總為邏輯單核（單位為百分比）

l eventloopLag：（任務）隊列延遲，每隔2秒采樣（單位為毫秒）

l libuv：I/O用量，將會上報activeHandles、activeRequests這兩個用量

各策略以平均值（Avg）、最大值（Max）、最小值（Min）分節(jié)點進行統(tǒng)計：

? 日志輸出

所有通過Console模塊（如console.log）輸出的日志，都會輸出到服務本地文件內(nèi)。并附加相關信息（如下），方便定位問題。

日志格式：日期時間|進程PID|日志級別|輸出文件名與行號|日志內(nèi)容

2018-07-0112:00:00|332|DEBUG|app.js:13|Serverrunningathttp://127.0.0.1:3000/

? LongStackTrace?

由于Node.js采用異步機制，在發(fā)生異常時堆棧不完整，導致定位問題復雜。

鑒于此，我們提供了長鏈路跟蹤技術在產(chǎn)生異常時自動附加前序調(diào)用堆棧，同時還支持在異常堆棧中過濾出用戶代碼部分。

由于開啟此特性時會造成性能損耗，故默認關閉，管理平臺等性能不敏感業(yè)務可直接通過配置開啟。

?案例說明

執(zhí)行上述代碼會拋出下述異常：

ReferenceError:ThisMayThrowErrorisnotdefined

atTimeout.setTimeoutas_onTimeout

at_disibledevent="http://superzheng.com/">@SuperZheng 創(chuàng)立于2017年。團隊成員均為全棧架構師（Super寓意Superman——無所不能），熟知Web(3D)、終端、后端與大數(shù)據(jù)計算，并由傳統(tǒng)前端向互聯(lián)網(wǎng)從業(yè)者方向發(fā)展。歡迎前端牛人加入，共創(chuàng)前端美好未來。