复习3-三栏布局/htttp/判断登录
大復習
文章目錄
- 大復習
- 三欄布局
- js獲取url中的某個參數值
- 閉包的作用
- WEB攻擊(說了SQL注入，XSS,CSRF 讓細講了CSRF的過程)前端安全這塊（問題，防范）
- 事件循環，宏任務微任務
- http頭部信息
- http狀態碼
- TLS握手
- Async，promise和generator
- ES6的新特性（說了塊級作用域、箭頭函數、promise順便問了事件循環，擴展運算符，Symbol和新增的幾個API
- 排序-快排/冒泡/插入
- CSS的position(重點relative 和absolute的區別)
- css垂直水平居中
- ES6中，promise,asynic ,await,setTimeout的異同
- eventloop/宏微任務
- flex布局
- 首屏等待時間長是怎么進行優化的？
- 說說滑動到底加載下一輪數據用原生是怎么實現的？
- 如果加載接下來的東西，會造成維持這個列表隊列里的其它東西被重復渲染，造成性能浪費，有沒有解決這個問題的方法？
- 防抖和節流
- 常見的性能優化怎么做的
- 怎么判斷一個用戶的登錄來源，怎么進行存儲操作
- 前端監控&前端埋點
三欄布局
原理是靠margin移動盒子,不設置寬度; 配合浮動或者定位
margin百分比是相對父元素寬度,這里父元素body
方法1:左邊左浮動,右邊右浮動,中間不設置寬度,靠左右margin撐開舉例
方法2:三欄全部左浮動, 不過中間欄寬度100%, 左邊欄margin-left是-100%, 即左移一個body的寬度, 靠左遮住中間欄; 右盒子margin-left:-自身寬度px
方法3:絕對定位,不用浮動, 但還是靠margin值撐開中間這個自適應大小的盒子
js獲取url中的某個參數值
使用js獲取url中的某個參數值，主要通過把url的參數轉換成數組形式，再通過for循環逐個查找數組元素，把參數值找出來。
1.使用location.href獲得當前頁面的鏈接, 此時是字符串形式
2.鏈接中的參數前有像? & 這種符號值, 為了一次用split分隔開, 可以先replace一些符號,然后變成數組
s=s.replace("?","?&").split("&");3.數組里元素可能是這樣[‘a=111’, ‘b=222’], 所以再按照等號split數組
4.最后遍歷,找a[i+1]即可
閉包的作用
1.模仿塊級作用域: 利用閉包會通過作用域鏈找變量,來模擬塊級作用域
2.利用函數傳的是值不是函數本身, 所以閉包里的改變不會污染外層全局變量
3.封裝私有變量我們可以把函數當作一個范圍，函數內部的變量就是私有變量，在外部無法引用，但是我們可以通過閉包的特點來訪問私有變量。
WEB攻擊(說了SQL注入，XSS,CSRF 讓細講了CSRF的過程)前端安全這塊（問題，防范）
事件循環，宏任務微任務
http頭部信息
https://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html
HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文
根據維基百科對http header內容的組織形式，大體分為Request和Response兩部分。
| Accept一類(-charset、-encoding，-language) | 指定客戶端能夠接受的類型 | |
| Cache-Control | 指定請求和響應遵循的緩存機制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久連接。（HTTP 1.1默認進行持久連接） | Connection: close、keep-alive |
| Cookie | HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。 | Cookie: $Version=1; Skin=new; |
| If-Modified-Since-觸發協商緩存 | 如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果內容未改變返回304代碼，參數為服務器先前發送的Etag，與服務器回應的Etag比較判斷是否改變 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| Host | 指定請求的服務器的域名和端口號-http1.1新增, 支持斷點重傳 | Host: www.zcmhi.com |
| Accept-Ranges | 表明服務器是否支持指定范圍請求及哪種類型的分段請求 | Accept-Ranges: bytes |
| Content(-Encoding, -Language, -Length) | 響應體的信息 | Content-Encoding: gzip |
| Cache-Control | 告訴所有的緩存機制是否可以緩存及哪種類型 | Cache-Control: no-cache |
| Last-Modified | 請求資源的最后修改時間 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Set-Cookie | 設置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Location | 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 | Location: http://www.zcmhi.com/archives/94.html |
Last-Modified/If-Modified-Since要配合Cache-Control使用, 判斷是否觸發協商緩存304;
http狀態碼
| 1xx：指示信息–表示請求已接收，繼續處理 | |
| 2xx：成功–表示請求已被成功接收、理解、接受 | 200 OK //客戶端請求成功-觸發強緩存 |
| 3xx：重定向–要完成請求必須進行更進一步的操作 | 301: |
| 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現 | 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解 401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用 403 Forbidden //服務器收到請求，但是拒絕提供服務 404 Not Found 請求資源不存在，eg：輸入了錯誤的URL |
| 5xx：服務器端錯誤–服務器未能實現合法的請求 | 500 Internal Server Error //服務器發生不可預期的錯誤 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常 |
200要么成功接到響應，要么表示強緩存，不會發送請求,因為本地緩存沒有過期;cache control: max-age=1年
TLS握手
https://www.cnblogs.com/barrywxx/p/8570715.html
客戶端計算所有接收信息的 hash 值，并采用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證通過則握手完成;
Async，promise和generator
https://es6.ruanyifeng.com/#docs/promise
https://es6.ruanyifeng.com/#docs/async
ES6的新特性（說了塊級作用域、箭頭函數、promise順便問了事件循環，擴展運算符，Symbol和新增的幾個API
排序-快排/冒泡/插入
CSS的position(重點relative 和absolute的區別)
css垂直水平居中
https://www.cnblogs.com/tllw/p/10374110.html
ES6中，promise,asynic ,await,setTimeout的異同
eventloop/宏微任務
flex布局
首屏等待時間長是怎么進行優化的？
首屏過長原因:
由抓包數據結合以上分析可能導致的原因有：
https://zhuanlan.zhihu.com/p/88639980
https://blog.51cto.com/u_15127571/2665856
1.利用好script標簽的async和defer這兩個屬性。功能獨立且不要求馬上執行的js文件，可以加入async屬性。如果是優先級低且沒有依賴的js，可以加入defer屬性。
2.減少請求的數量。這點在http1.1的優勢很明顯，因為http1.1的請求是串行的（盡管有多個tcp通道），每個請求都需要往返后才能繼續下個請求; 比如用: 精靈圖
3.引入http2.0。http2.0對比http1.1，最主要的提升是傳輸性能，在接口小而多的時候會更加明顯。
4.前端的資源動態加載：
a. 路由動態加載，最常用的做法，以頁面為單位，進行動態加載。 b. 組件動態加載(offScreen Component)，對于不在當前視窗的組件，先不加載。 c. 圖片懶加載(offScreen Image)，同上。值得慶幸的是，越來越多的瀏覽器支持原生的懶加載，通過給img標簽加上loading="lazy來開啟懶加載模式。5.cdn分發（減少傳輸距離）。通過在多臺服務器部署相同的副本，當用戶訪問時，服務器根據用戶跟哪臺服務器距離近，來決定哪臺服務器去響應這個請求。
6.（少用）選擇先進的圖片格式。使用 WebP 的圖片格式來代替現有的jpeg和png，當頁面圖片較多時，這點作用非常明顯。把部分大容量的圖片從BaseLine JPEG切換成Progressive JPEG（理解這兩者的差別）也能縮小體積。
說說滑動到底加載下一輪數據用原生是怎么實現的？
如果加載接下來的東西，會造成維持這個列表隊列里的其它東西被重復渲染，造成性能浪費，有沒有解決這個問題的方法？
防抖和節流
防抖和節流及應用場景？
常見的性能優化怎么做的
渲染方式、數據處理，后端、網絡通信相關的所有內容；
入手：基于http請求響應的這一系列過程，有幾個問題：
如何讓網絡通信更快，發請求更快？
盡量用http2不要用http1；首先http2有頭部壓縮機制，谷歌專門提出一個HPACK壓縮算法，傳一個索引表（只存常用頭信息），輔助哈夫曼編碼來encode頭id；其次http2真正實現了多路復用（2進制幀傳數據）；
服務器層面：物理距離無法更改，但是如果有多個服務器，選擇近距離的服務器,但是如果最近點負載過高，就選擇次近點；CDN: content delivery network服務器通信層面；原理像物流倉庫
如果只能http1，以下方法用來優化http1：
合并資源（雪碧圖），減少http請求數量，避免不停建立鏈接
域名分片：HTTP 里“并發連接”（concurrent connections），也就是同時對一個域名發起多個長連接，用數量來解決質量的問題。
如果每個客戶端都想自己快，建立很多個連接，用戶數×并發數就會是個天文數字。服務器的資源根本就扛不住，或者被服務器認為是惡意攻擊，反而會造成“拒絕服務”。HTTP 協議和瀏覽器不是限制并發連接數量嗎？好，那我就多開幾個域名，比如 shard1.chrono.com、shard2.chrono.com，而這些域名都指向同一臺服務器 www.chrono.com，這樣實際長連接的數量就又上去了
緩存機制（強緩存，協商緩存）。做法：第一次請求后，服務器給客戶端設置頭部cache-control或者expires，讓客戶端自己決定下次請求是否觸發強緩存；客戶端第二次請求時頭部有if-modified-since給自己設定時間，服務器再根據lastmodified判斷是否觸發協商緩存；
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-lyk6iryw-1621958664017)(…/…/AppData/Roaming/Typora/typora-user-images/image-20210427155436132.png)]
用算法進行數據壓縮（gzip、br）
代碼文件壓縮：HTML/CSS/JS中的注釋，空格，長變量名等等，webpack打包工具；less/sass等
靜態資源：字體圖標，縮小尺寸，使用jpg/webp格式
頭與報文：http1.1壓縮頭部，http2就有這個機制；
我自己的話用了精靈圖和less
服務器如何讓數據處理更快，處理數據，回復請求更快？
客戶端如何讓數據處理更快，客戶端拿到數據后，怎么更快顯示
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-NXH4zPUt-1621958664020)(…/…/AppData/Roaming/Typora/typora-user-images/image-20210427162507215.png)]
怎么判斷一個用戶的登錄來源，怎么進行存儲操作
登錄成功后生成Cookie響應給客戶端
登錄成功之后將登錄用戶的id，用戶類型，用戶來源平臺，登錄時間等信息序列化成字符串，然后再通過對稱加密，生成一個字符串作為cookie的value值響應給客戶端。
java的HttpServletResponse對象包含登錄用戶的id，用戶類型，用戶來源平臺，登錄時間等信息, 代碼如下：
public void createCookieAndRegisterDevice(LoginVO loginVO, HttpServletRequest httpServletRequest,HttpServletResponse httpServletResponse,String[] cookieDomains) throws Exception {AuthCookieItem authCookieItem = CookieUtils.createCookie(userType2ApiType(loginVO.getUserType()), loginVO.getUserType(), loginVO.getUserId());//設置登錄時間戳long now = System.currentTimeMillis();authCookieItem.setTimestamp(now);String deviceId = httpServletRequest.getHeader("DeviceId");if (StringUtils.isNotBlank(deviceId)) {doUserSysRedis(authCookieItem.getUserId(), now, deviceId);}String cookieValue = CookieUtils.encryptCookie(authCookieItem, AES.CookieKey).replaceAll("\\n|\\r", "");writeCookie(httpServletResponse,cookieDomains,cookieValue); }js怎么寫存儲cookie:https://www.jb51.net/article/162229.htm
js存放cookie一般的寫法，如：document.cookie="userName=admin";，如果是多個鍵值對：document.cookie="userName=admin; userPass=123";
前端監控&前端埋點
https://segmentfault.com/a/1190000015864670
實現前端監控有三個步驟：前端埋點和上報、數據處理和數據分析。
我對數據處理和分析不太了解，不過試過前端埋點和上報；
埋點分三種，簡單的需求可以代碼埋點直接獲取數據，然后上報方式的話可以用Image實例的src上傳，get請求，無跨域兼容問題；或者navigator.sendBeacon("/log", analyticsData);navigator對象的sendBeacon方法；
更多的關于瀏覽器渲染方面的數據，可以用performance接口獲取；
1.目前常見的前端埋點方法分為三種：代碼埋點、可視化埋點和無痕埋點。
(1) 代碼埋點
代碼埋點，就是以嵌入代碼的形式進行埋點，比如需要監控用戶的點擊事件，會選擇在用戶點擊時，插入一段代碼，保存這個監聽行為或者直接將監聽行為以某一種數據格式直接傳遞給server端。
(2)可視化埋點
通過可視化交互的手段，代替代碼埋點。將業務代碼和埋點代碼分離，提供一個可視化交互的頁面，輸入為業務代碼，通過這個可視化系統，可以在業務代碼中自定義的增加埋點事件等等，最后輸出的代碼耦合了業務代碼和埋點代碼。
可視化埋點聽起來比較高大上，實際上跟代碼埋點還是區別不大。也就是用一個系統來實現手動插入代碼埋點的過程。
(3)無埋點
無埋點并不是說不需要埋點，而是全部埋點，前端的任意一個事件都被綁定一個標識，所有的事件都別記錄下來。通過定期上傳記錄文件，配合文件解析，解析出來我們想要的數據，并生成可視化報告供專業人員分析因此實現“無埋點”統計。
從語言層面實現無埋點也很簡單，比如從頁面的js代碼中，找出dom上被綁定的事件，然后進行全埋點。
2.埋點監控到數據后，怎么傳給服務器
可以用img的ping方法提交簡單的信息，數據通過 Image 對象實例的 src 屬性指向后端腳本并攜帶參數
可以用fetch和POST方法提交表單，可以XMLHttpRequest
Performance 接口可以獲取到當前頁面中與性能相關的信息。它是 High Resolution Time API 的一部分，同時也融合了 Performance Timeline API、Navigation Timing API、 User Timing API 和 Resource Timing API。
總結
以上是生活随笔為你收集整理的复习3-三栏布局/htttp/判断登录的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 计算机上的查找替换功能快速格式化,Wor
- 下一篇： 南北流量和东西流量