предговор
HTTP протоколът е един от най-важните протоколи в интернет, макар да изглежда прост, но на практика често среща проблеми и сме се сблъсквали с него няколко пъти. Има дълги връзки и парсинг на пакети. Не можеш да знаеш нищо за HTTP протокола, трябва да го разбираш напълно. Затова написах тази поредица, за да споделя проблемите и опита с HTTP протокола.
HTTP протоколът има хедър и тяло както за заявката, така и за отговорните пакети, а тялото е ресурсът, който искате да получите, като html страница, jpeg изображение, а хедърът се използва за създаване на определени конвенции. Например, клиентът и сървърът се съгласяват за някои формати за предаване, и клиентът първо получава заглавието, знае част от формата и след това започва да чете основното съдържание.
Клиент: Accept-Encoding:gzip (компресирай го за мен, използвам трафик, първо го изтегли и после бавно го разархивирам)
Сървър 1: Content-Encoding: null (No Content-Encoding header.) Не давам компресия, процесорът не е свободен, искаш ли го?
Сървър 2: Content-Encoding:gzip (запазвам трафика за теб, компресирам) Клиент: Връзка: keep-alive (Голям брат, най-накрая изградихме TCP връзка, ще я използваме следващия път)
Сървър 1: Връзка: поддържане на живо (не е лесно, продължавай да използваш)
Сървър 2: Връзка: близо (Който и да продължи да го използва с вас, нашият TCP е еднократен и следващия път ще трябва да се свържем отново) HTTP протоколът няма три ръкостискания, и когато клиент поиска ресурси от сървъра, сървърната страна надделява. Има и някои хедъри, които нямат процес на преговори, но сървърът директно казва на клиента какво да прави. Например, горната дължина на съдържанието е това, което сървърът казва на клиента колко голямо е тялото. Но! Сервитьорът може да не може да ви каже точно колко голямо е тялото предварително. Сървърът трябва първо да напише заглавието, а след това и тялото, ако искате да напишете корпуса в заглавието, трябва предварително да знаете размера на тялото. Ако тялото се генерира динамично, сървърът ще приключи и след това ще започне да пише заглавието, което изисква много допълнителни разходи, така че може да няма дължина на съдържанието в заглавието.
Как тогава клиентът знае размера на тялото? Сървърът ви казва по три начина.
1. Сървърът вече знае размера на ресурса и ви го казва чрез заглавието за дължина на съдържанието.
Content-Length:1076(body的大小是1076B,你读取1076B就可以完成任务了)
Transfer-Encoding: null
2. Сървърът не може да знае размера на ресурса предварително или не желае да харчи ресурси за изчисляване на размера му предварително, затова ще добави хедър към http отговорното съобщение, наречено Transfer-Encoding:chunked, което означава прехвърляне на блокове. Всеки блок използва фиксиран формат, с размера на блока отпред, данните зад него и след това последния блок с размер 0. По този начин, когато клиентът парсира, трябва да обърне внимание на премахването на някои безполезни полета.
Content-Length:null
Transfer-Encoding:chunked (接下来的body我要一块一块的传,每一块开始是这一块的大小,等我传到大小为0的块时,就没了)
3. Сървърът не знае размера на ресурса и не поддържа режим на предаване с чънк, така че няма нито заглавие с дължина на съдържанието, нито заглавие за кодиране на трансфер. В този момент заглавието, върнато от сървъра, трябва да е близо.
Content-Length:null
Transfer-Encoding:null
Connection:close(我不知道大小,我也用不了chunked,啥时候我关了tcp连接,就说明传输结束了)
|