Kelahiran Cookie
Karena protokol HTTP adalah stateless, layanan sisi server harus stateful. Tujuan asli dari kelahiran cookie adalah untuk menyimpan informasi status di web agar mudah digunakan di sisi server. Misalnya, tentukan apakah pengguna mengunjungi situs web untuk pertama kalinya. Spesifikasi terbaru adalah RFC 6265, yang merupakan spesifikasi yang diimplementasikan oleh server browser.
Pemrosesan cookie dibagi menjadi:
Server mengirimkan cookie seperti klien
Browser menyimpan cookie
Setelah itu, setiap kali permintaan HTTP diminta, browser akan mengirim cookie ke server.
Kirim dan Parsing di Sisi Server
Kirim cookie
Cookie sisi server yang dikirim oleh klien diimplementasikan melalui paket respons HTTP. Dalam set-Cookies, cookie yang perlu dikirim oleh klien ditetapkan. Format cookie adalah sebagai berikut:
Set-cookie: "name = value; domain = .domain.com; path =/; kedaluwarsa = sat, 11 Jun 2016 11:29:42 GMT; httponly; aman"
Di mana nama = nilai adalah opsi yang diperlukan, dan lainnya opsional. Komponen utama cookie adalah sebagai berikut:
Nama: Nama kue yang unik dan pasti. Secara umum, nama cookie tidak sensitif.
Nilai: Nilai string yang disimpan dalam cookie. Yang terbaik adalah URL yang mengkode nama dan nilai cookie
Domain: Cookie berlaku untuk domain mana. Semua permintaan yang dikirim ke domain ini akan berisi informasi cookie ini. Nilai ini dapat berisi subdomain (seperti:
yq.aliyun.com) atau tidak dapat dimasukkan (misalnya: .aliyun.com, ini berlaku untuk semua subdomain dari aliyun.com).
Jalur: Menunjukkan jalur yang dipengaruhi oleh cookie ini. Browser akan mengirim cookie berdasarkan konfigurasi ini, seperti pencocokan jalur di domain yang ditentukan.
Kedaluwarsa: Waktu kedaluwarsa, cap waktu yang menunjukkan kapan cookie harus dihapus (yaitu, kapan cookie harus berhenti dikirim ke server). Jika Anda tidak mengatur cap waktu ini, browser akan menghapus semua cookie saat halaman ditutup; Namun, Anda juga dapat mengatur waktu penghapusan sendiri. Nilai ini dalam format waktu GMT. Jika waktu klien dan server tidak konsisten, akan ada penyimpangan saat menggunakan kedaluwarsa.
MAX-AGE: Fungsi yang sama dengan kedaluwarsa, digunakan untuk memberi tahu browser berapa lama cookie ini kedaluwarsa (dalam detik), daripada titik waktu yang tetap. Dalam keadaan normal, usia maksimum memiliki prioritas yang lebih tinggi daripada kedaluwarsa.
Httponly: menginformasikan browser untuk tidak mengizinkan dokumen skrip.cookie mengubah nilai ini, dan nilai ini juga tidak terlihat di document.cookie. Tapi cookie ini masih akan dibawa berdasarkan permintaan HTTP. Perhatikan bahwa meskipun nilai ini tidak tersedia dalam skrip, itu masih ada di direktori instalasi browser sebagai file. Pengaturan ini biasanya diatur di sisi server.
Aman: Bendera keamanan, setelah menentukan, itu hanya dapat dikirim ke server saat menggunakan tautan SSL. Jika ini adalah tautan HTTP, informasi ini tidak akan dilewati. Bahkan jika atribut aman diatur, itu tidak berarti bahwa orang lain tidak dapat melihat informasi cookie disimpan secara lokal di mesin Anda, jadi jangan masukkan informasi penting ke dalam cookie dan atur tepat di sisi server.
Contoh cookie adalah sebagai berikut:
var http = membutuhkan ('http'); var fs = membutuhkan ('fs'); http.createServer (function (req, res) {res.setheader ('status', '200 ok'); res.setheader ('set-cookie', 'isVisit = true; domain = .yourdomain.com; hamphe = aage = 1000; 1000; 1000; 1000; 1000; 1000; domain =. Dunia '); res.end ();}). Dengarkan (8888); Console.log (' Menjalankan Localhost: 8888 ')Mengatur Set-Cookie secara langsung terlalu asli. Kita dapat merangkum proses pengaturan cookie sebagai berikut:
var serilize = function (name, val, options) {if (! name) {throw new error ("cooleie harus memiliki nama"); } var enc = encodeuricomponent; var bagian = []; val = (val! == null && val! == tidak ditentukan)? val.tostring (): ""; opsi = opsi || {}; parts.push (enc (name) + "=" + enc (val)); // Harus ada dua titik di domain if (options.domain) {parts.push ("domain =" + options.domain); } if (options.path) {parts.push ("path =" + options.path); } // Jika Anda tidak mengatur kedaluwarsa dan browser maksimal akan menghapus cookie saat halaman ditutup jika (options.expires) {parts.push ("Expires =" + options.expires.togmtString ()); } if (options.maxage && typeof options.maxage === "angka") {parts.push ("max-age =" + options.maxage); } if (options.httponly) {parts.push ("httponly"); } if (options.secure) {parts.push ("aman"); } return parts.join (";");}Perlu dicatat bahwa jika cookie diatur ke masa lalu, browser akan segera menghapus cookie; Selain itu, item domain harus memiliki dua poin, sehingga tidak dapat diatur ke localhost:
Sesuatu yang tidak jelas bagi saya di sini dan benar -benar membuat saya bingung untuk sementara waktu adalah bahwa nama domain harus berisi setidaknya dua titik (.), Oleh karena itu 'localhost' tidak valid dan browser akan menolak untuk mengatur cookie!
Cookie Analisis Sisi Server
Cookie dapat mengatur domain dan jalur yang berbeda, jadi untuk nilai nama yang sama, dapat diulangi di bawah jalur yang berbeda di domain yang berbeda dan jalur yang berbeda. Browser akan mengurutkan pesanan dalam urutan yang paling cocok dengan URL atau alamat halaman yang diminta saat ini.
Jadi ketika cookie diteruskan ke sisi server di sisi saat ini memiliki beberapa nilai nama duplikat, kami hanya membutuhkan yang paling cocok, yaitu, yang pertama. Kode parsing sisi server adalah sebagai berikut:
var parse = function (cstr) {if (! cstr) {return null; } var dec = decodeuricomponent; var cookies = {}; var bagian = cstr.split (// s*;/s*/g); Parts.foreach (function (p) {var pos = p.indexof ('='); // Nama dan Nilai harus dikodekan sebelum cookie disimpan var name = pos> -1? Dec (p.substr (0, pos)): p; val val = pos> -1 dec (p.substr (pos + 1)): null; / /hanya kebutuhan yang dibutuhkan untuk Anda kebutuhan. cookie [name] = val;}/* lain jika (! Cookies [nama] dari array) {cookies [name] = [cookie [name]]. Push (val); mengembalikan cookie;}Akses Klien
Browser mengelola cookie yang dilewati di latar belakang dan memungkinkan pengembang untuk menggunakan dokumen. Cookies di JavaScript untuk mengakses cookie. Tetapi antarmuka ini sangat timpang untuk digunakan. Ini akan menunjukkan perilaku yang berbeda karena berbagai cara yang digunakan.
Ketika digunakan untuk mendapatkan nilai atribut, Document.cookie mengembalikan semua string yang tersedia di halaman saat ini (berdasarkan domain cookie, jalur, waktu kedaluwarsa dan pengaturan keamanan). Format string adalah sebagai berikut:
"name1 = value1; name2 = value2; name3 = value3";
Saat digunakan untuk menetapkan nilai, properti Document.cookie dapat diatur ke string cookie baru. String ini ditafsirkan dan ditambahkan ke koleksi cookie yang ada. menyukai:
document.cookie = "_fa = aaaffffasdsf; domain = .dojotoolkit.org; path =/"
Pengaturan dokumen.
Karena sangat tidak nyaman untuk membaca dan menulis cookie, kami dapat merangkum beberapa fungsi untuk menangani cookie, terutama untuk penambahan, modifikasi dan penghapusan cookie.
var cookieutils = {get: function (name) {var cookiename = encodeuricomponent (name) + "="; // Hanya dapatkan nama yang paling cocok, nilai var cookiestart = document.cookie.indexof (cookiename); var cookievalue = null; if (cookiestArt> -1) {// dari cookiestart var cookieend = document.cookie.indexof (';', cookiestArt); // from = after = (cookieEnd> -1) {cookievalue = decodeuricomponent (document.cookie.substring (cookiestart + cookiename.length, cookieEnd)); } else {cookievalue = decodeuricomponent (document.cookie.substring (cookiestart + cookiename.length, document.cookie.length)); }} return cookievalue; }, atur: function (name, val, options) {if (! name) {throw new error ("coudie harus memiliki nama"); } var enc = encodeuricomponent; var bagian = []; val = (val! == null && val! == tidak ditentukan)? val.tostring (): ""; opsi = opsi || {}; parts.push (enc (name) + "=" + enc (val)); // domain harus berisi dua titik jika (options.domain) {parts.push ("domain =" + options.domain); } if (options.path) {parts.push ("path =" + options.path); } // Jika Anda tidak mengatur kedaluwarsa dan browser maksimal akan menghapus cookie saat halaman ditutup jika (options.expires) {parts.push ("Expires =" + options.path); } // Jika Anda tidak mengatur kedaluwarsa dan browser maksimal akan menghapus cookie saat halaman ditutup jika (options.expires) {parts.push ("Expires =" + options.expires.togmtString ()); } if (options.maxage && typeof options.maxage === "angka") {parts.push ("max-age =" + options.maxage); } if (options.httponly) {parts.push ("httponly"); } if (options.secure) {parts.push ("aman"); } document.cookie = parts.join (";"); }, hapus: function (name, options) {options.expires = Tanggal baru (0); // Setel ke tanggal lewat this.set (name, null, options); }}Keuntungan caching
Yang biasa disebut sebagai cache web mengacu pada perangkat HTTP yang secara otomatis dapat menyimpan salinan permintaan HTTP umum. Untuk pengembang front-end, browser memainkan peran penting. Selain itu, ada berbagai server proxy umum yang juga dapat digunakan untuk caching. Ketika permintaan web mencapai cache, cache mengekstrak konten replika dari replika lokal tanpa melewati server. Ini membawa keuntungan berikut:
Caching mengurangi transmisi data yang berlebihan dan menyimpan lalu lintas
Cache mengurangi masalah kemacetan bandwidth. Halaman dapat dimuat lebih cepat tanpa lebih banyak bandwidth
Cache meringankan kemacetan instan dan mengurangi persyaratan untuk server asli.
Cache mengurangi penundaan jarak karena memuat halaman dari tempat yang lebih jauh akan lebih lambat.
Jenis cache
Cache dapat didedikasikan untuk satu pengguna atau dibagikan oleh banyak pengguna. Cache khusus disebut cache pribadi, dan cache bersama disebut cache publik.
Cache pribadi
Cache pribadi hanya untuk pengguna berpemilik, sehingga tidak memerlukan banyak ruang dan murah. Browser web memiliki cache pribadi bawaan - sebagian besar browser akan menemui sumber daya umum pada disk dan memori PC Anda. Misalnya, lokasi penyimpanan cache dari browser Chrome adalah: C:/USERS/YOUS_ACCOUNT/APPDATA/LOKAL/GOOGLE/DATA PENGGUNA/DATA PENGGUNA/DEFAULT.
Cache publik
Cache publik adalah server proxy bersama khusus, yang disebut server proxy cache atau cache proxy (tujuan proxy terbalik). Cache publik akan menerima akses dari banyak pengguna, sehingga dapat mengurangi lalu lintas yang lebih redundan.
Pada gambar di bawah ini, setiap klien akan berulang kali mengakses sumber daya ke server (tidak ada dalam cache pribadi saat ini), sehingga akan mengakses server beberapa kali, meningkatkan tekanan pada server. Saat menggunakan cache publik bersama, cache hanya perlu diambil dari server sekali dan tidak harus melewati server di masa depan, yang dapat secara signifikan mengurangi tekanan pada server.
Bahkan, cache publik hierarkis biasanya digunakan dalam aplikasi aktual. Ide dasarnya adalah menggunakan cache kecil dan murah di dekat klien, sedangkan di level yang lebih tinggi, cache yang lebih besar dan lebih kuat secara bertahap diadopsi untuk memuat sumber daya yang dibagikan oleh banyak pengguna.
Aliran pemrosesan cache
Untuk pengembang front-end, kami terutama berurusan dengan cache di browser, sehingga proses di atas disederhanakan untuk:
Gambar berikut menunjukkan hasil permintaan situs web untuk sumber daya yang berbeda. Dapat dilihat bahwa beberapa sumber daya dibaca langsung dari cache, beberapa sumber daya dihormati dengan server, dan beberapa sumber daya diperoleh ulang dari server.
Perhatikan bahwa semua pertanyaan yang kita bahas tentang sumber daya cache hanya untuk permintaan mendapatkan. Untuk operasi perilaku seperti post, hapus, dan put, biasanya tidak ada cache.
Batas kesegaran
HTTP menyimpan salinan sumber daya server untuk jangka waktu tertentu melalui cache, yang disebut batas kesegaran. Ini meminta sumber daya yang sama untuk jangka waktu tertentu dan tidak akan melewati server lagi. Cache-control dan kedaluwarsa dalam protokol HTTP dapat digunakan untuk menetapkan batas kesegaran. Yang pertama adalah header respons baru yang ditambahkan dalam http1.1, dan yang terakhir adalah header respons di http1.0. Keduanya melakukan hal yang sama, tetapi karena kontrol cache menggunakan waktu relatif, dan kedaluwarsa mungkin memiliki masalah bahwa waktu klien dan server berbeda, kami lebih suka kontrol cache.
Kontrol cache
Mari kita lihat nilai atribut apa yang dapat ditetapkan oleh cache-control:
MAX-AGE (Unit adalah S) menentukan waktu maksimum yang valid untuk mengatur cache, yang menentukan lamanya waktu. Ketika browser mengirim permintaan ke server, browser tidak akan lagi mengirim permintaan ke server selama usia maksimum.
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" /> <meta http-equiv="X-UA-Compatible" content="IE=EDGE" /> <Title> cache web </iteme> <tautan rel = "ikon shortcut" href = "./ shortcut.png"> <script> </script> </head> <body> <img src = "./ Cache.png"> </body> </html> var http = ('http ='; memerlukan ('fs'); http.createServer (function (req, res) {if (req.url === '/' || req.url === '' || req.url === '/index.html') {fs.readfile ('./index.html', function. Cache untuk dokumen utama, res.setHeader ('Cache-Control', "No-Cache, Max-Age =" + 5); fs.readfile ('./ cache.png', function (err, file) {res.setHeader ('cache-control', "max-seage =" + 5); // cache lima detik res.setHeader ('tipe konten', 'gambar/png'); res.writeHead ('200', "bukan konten"); }). Dengarkan (8888)Ketika halaman diakses untuk kedua kalinya dalam 5 detik, browser akan langsung mendapatkan sumber daya dari cache
Publik menentukan bahwa respons dapat di -cache dalam cache proxy dan karenanya dapat dibagikan oleh banyak pengguna. Jika pribadi tidak ditentukan secara eksplisit, itu default untuk umum.
Respons pribadi hanya dapat di -cache dalam cache pribadi dan tidak dapat ditempatkan pada cache proxy. Sumber daya yang peka terhadap beberapa informasi pengguna biasanya perlu diatur ke pribadi.
No-Cache berarti bahwa Anda harus terlebih dahulu mengonfirmasi dengan server apakah sumber daya telah diubah (mengandalkan If-None-Match dan Etag) sebelum memutuskan apakah akan menggunakan cache lokal.
Jika pemrosesan cache di atas diubah menjadi berikut, setiap kali Anda mengunjungi halaman, browser perlu pergi ke server untuk memverifikasi apakah sumber daya telah diubah.
fs.readfile ('./ cache.png', function (err, file) {console.log (req.headers); console.log (req.url) if (! req.headers ['if-none-match']) {res.setheader ('cache-control', "no-cache, max-reage =" resetheader ('cache-control', "no-cache, max-reage =" resetheader ('cache-control', "no-cache, max-reage =" resetheader ('cache-control', "no no-cache, max-aage =" ressetheader ('cache-control' 'Png'); res.setHeader ('Cache-Control', "Max-AGE =" + 5);No-store benar-benar melarang cache sumber daya apa pun, yang berarti bahwa setiap kali pengguna meminta sumber daya, permintaan akan dikirim ke server, dan sumber daya lengkap akan diunduh setiap saat. Biasanya digunakan untuk sumber daya rahasia.
Mengenai penggunaan cache-control, lihat gambar di bawah ini (dari jumlah besar)
Batas kesegaran klien
Kontrol cache tidak hanya dapat diatur di header respons, tetapi juga di header permintaan. Browser dapat memutuskan apakah akan membaca sumber daya dari cache dengan mengatur kontrol cache di header permintaan. Ini juga mengapa kadang -kadang mengklik tombol refresh browser dan masuk ke bilah alamat untuk melihat hasil yang sama sekali berbeda dalam modul jaringan
Kedaluwarsa
Kedaluwarsa tidak disarankan, itu menentukan tanggal kedaluwarsa tertentu daripada sejumlah detik. Karena banyak server dan klien memiliki jam yang tidak konsisten, yang terbaik adalah menggunakan cache-control.
Verifikasi Server
Sumber daya yang di -cache di browser atau cache proxy tidak berarti tidak berarti bahwa itu sebenarnya berbeda dari sumber daya di server asli, tetapi hanya berarti saatnya untuk memeriksa. Situasi ini disebut verifikasi ulang server.
Jika sumber daya berubah, Anda perlu mendapatkan sumber daya baru dan mengganti sumber daya lama di cache.
Jika sumber daya tidak berubah, cache hanya perlu mendapatkan header respons baru dan waktu kedaluwarsa baru untuk memperbarui waktu kedaluwarsa sumber daya dalam cache.
Metode verifikasi yang disarankan untuk http1.1 adalah jika tidak-none-match/etag, dan if-modified-since/terakhir dimodifikasi digunakan dalam http1.0.
Etag dan If-None-Match
Menghasilkan string hash berdasarkan konten entitas, mengidentifikasi status sumber daya, dan dihasilkan oleh server. Browser akan meneruskan string ini kembali ke server untuk memverifikasi bahwa sumber daya telah dimodifikasi. Jika belum dimodifikasi, prosesnya adalah sebagai berikut (gambar berasal dari diskusi singkat tentang cache web):
Dalam demo di atas, kami telah melihat cara memverifikasi ETAG di server:
Karena ETAG memiliki struktur server, keunikan Etag harus dipastikan di lingkungan cluster
IF-Modified-Since vs Last-Modified
Keduanya adalah header permintaan/respons yang digunakan dalam HTTP 1.0 untuk memverifikasi apakah sumber daya telah kedaluwarsa. Kedua header ini adalah tanggal. Proses verifikasi mirip dengan ETAG, jadi kami tidak akan memperkenalkannya secara rinci di sini. Saat menggunakan dua header ini untuk memverifikasi bahwa sumber daya diperbarui, ada masalah berikut:
Beberapa sumber daya dokumen ditulis ulang secara berkala, tetapi konten yang sebenarnya tidak berubah. Pada saat ini, metadata file akan menunjukkan bahwa tanggal modifikasi terbaru file berbeda dari IF-Modified-Since, menghasilkan tanggapan yang tidak perlu.
Beberapa sumber daya dokumen telah dimodifikasi, tetapi konten modifikasi tidak penting, dan semua cache tidak harus diperbarui (seperti komentar kode)
Mengenai pembaruan cache, silakan periksa jawaban Zhang Yunlong di sini. Artikel ini tidak akan diperluas secara rinci.
Kode demo dalam artikel ini adalah sebagai berikut:
<!DOCTYPE HTML><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" /> <meta http-equiv="X-UA-Compatible" content="IE=EDGE" /> <title>Web Cache</title> <link rel="shortcut icon" href="./shortcut.png"> <script> </script> </head> <body> <img src="./cache.png"> </body></html>var http = require('http');var fs = memerlukan ('fs'); http.createServer (function (req, res) {if (req.url === '/' || req.url === '' || req.url === '/index.html') {fs.readfile ('./index.html', function. Cache untuk dokumen utama, No Effect Res.setHeader ('Cache-Control', "No-Cache, Max-Age =" + 5); fs.readfile ('./ shortcut.png', function (err, file) {console.log (req.url) res.setHeader ('content-type', 'images/png'); res.writeHead ('200', "ok"); res.end (file);})} if (req.url = "ok"); end (file);})} if (req.url = == "); fs.readfile ('./ cache.png', function (err, file) {console.log (req.headers); console.log (req.url) if (! req.headers ['if-none-match']) {res.setHeader ('cache-control', "max-seage '); res.setheader ('etag', "ffff"); "Max =" + 5);Oke, pengantar artikel ini ke cookie berakhir di sini, saya harap semua orang menyukainya.