การเชื่อมต่อแบบถาวรของ HTTPหรือที่เรียกว่า HTTP keep-aliveหรือ HTTP connection reuseคือแนวคิดของการใช้ การเชื่อมต่อ TCP เดียว ในการส่งและรับคำขอ/การตอบกลับ HTTP หลายรายการ แทนที่จะเปิดการเชื่อมต่อใหม่สำหรับทุกคู่คำขอ/การตอบกลับ โปรโตคอล HTTP/2 ที่ใหม่กว่า ใช้แนวคิดเดียวกันนี้และพัฒนาต่อไปเพื่อให้สามารถส่งคำขอ/การตอบกลับพร้อมกันหลายรายการผ่านการเชื่อมต่อเดียวได้

ภายใต้ HTTP 1.0 การเชื่อมต่อควรถูกปิดโดยเซิร์ฟเวอร์เสมอหลังจากส่งการตอบกลับ^{[ 1 ]}

ตั้งแต่ช่วงปลายปี 1995 เป็นอย่างน้อย^{[ 2 ]}นักพัฒนาผลิตภัณฑ์ยอดนิยม (เบราว์เซอร์ เว็บเซิร์ฟเวอร์ ฯลฯ) ที่ใช้ HTTP/1.0 เริ่มเพิ่มส่วนขยายที่ไม่เป็นทางการ (ให้กับโปรโตคอล) ที่ชื่อว่า "keep-alive" เพื่ออนุญาตให้ใช้การเชื่อมต่อซ้ำสำหรับการร้องขอ/การตอบกลับหลายครั้ง^{[ 3 ] [ 4 ]}

หากไคลเอ็นต์รองรับ keep-alive ระบบจะเพิ่มส่วนหัวเพิ่มเติมลงในคำขอ:

การเชื่อมต่อ: keep-alive 

เมื่อเซิร์ฟเวอร์ได้รับคำขอและสร้างการตอบกลับ หากเซิร์ฟเวอร์รองรับ keep-alive ก็จะเพิ่มส่วนหัวเดียวกันกับข้างต้นลงในการตอบกลับด้วย หลังจากนั้น การเชื่อมต่อจะไม่ถูกตัด แต่จะยังคงเปิดอยู่ เมื่อไคลเอนต์ส่งคำขออื่น ก็จะใช้การเชื่อมต่อเดียวกันนั้น

กระบวนการนี้จะดำเนินต่อไปจนกว่าฝ่ายใดฝ่ายหนึ่งจะตัดสินใจว่าการสนทนาสิ้นสุดลงแล้ว และในกรณีนี้ พวกเขาจะลบส่วน"Connection:"หัวออกจากข้อความสุดท้ายที่ส่งไป หรือที่ดีกว่านั้นคือ พวกเขาจะเพิ่มคำว่า "close" ต่อท้ายข้อความนั้น

การเชื่อมต่อ: ปิด 

หลังจากนั้น การเชื่อมต่อจะถูกปิดตามกฎที่กำหนดไว้

ตั้งแต่ปี พ.ศ. 2540 ข้อกำหนด HTTP/1.1 เวอร์ชันต่างๆ ยอมรับการใช้งานส่วนขยายที่ไม่เป็นทางการนี้ และรวมข้อควรระวังบางประการเกี่ยวกับการทำงานร่วมกันระหว่างไคลเอ็นต์/เซิร์ฟเวอร์ HTTP/1.0 (keep-alive) และ HTTP/1.1 ^{[ 5 ]}

ใน HTTP 1.1 การเชื่อมต่อทั้งหมดจะถือว่าเป็นการเชื่อมต่อแบบถาวร เว้นแต่จะประกาศเป็นอย่างอื่น^{[ 5 ]}การเชื่อมต่อแบบถาวรของ HTTP ไม่ได้ใช้ข้อความ keepalive แยกต่างหาก แต่จะอนุญาตให้คำขอหลายรายการใช้การเชื่อมต่อเดียว อย่างไรก็ตาม เวลาหมดอายุการเชื่อมต่อเริ่มต้นของ Apache httpd 1.3 และ 2.0 นั้นสั้นเพียง 15 วินาที^{[ 6 ] [ 7 ]}และเพียง 5 วินาทีสำหรับ Apache httpd 2.2 ขึ้นไป^{[ 8 ] [ 9 ]} ข้อดีของเวลาหมดอายุที่สั้นคือความสามารถในการส่งมอบส่วนประกอบหลายส่วนของเว็บเพจได้อย่างรวดเร็วโดยไม่ต้องใช้ทรัพยากรในการเรียกใช้กระบวนการหรือเธรดเซิร์ฟเวอร์หลายตัวเป็นเวลานานเกินไป^{[ 10 ]}

Keepalive ทำให้ไคลเอนต์ระบุจุดสิ้นสุดของการตอบสนองหนึ่งและจุดเริ่มต้นของการตอบสนองถัดไปได้ยาก โดยเฉพาะอย่างยิ่งในระหว่างการดำเนินการ HTTP แบบ pipelined ^{[ 11 ]}นี่เป็นปัญหาที่ร้ายแรงเมื่อContent-Lengthไม่สามารถใช้งานได้เนื่องจากการสตรีม^{[ 12 ]}เพื่อแก้ปัญหานี้ HTTP 1.1 ได้แนะนำการเข้ารหัสการถ่ายโอนแบบ chunkedซึ่งกำหนดlast-chunkบิต^{[ 13 ]} บิต นี้last-chunkจะถูกตั้งค่าเมื่อสิ้นสุดการตอบสนองแต่ละครั้ง เพื่อให้ไคลเอนต์รู้ว่าจุดเริ่มต้นของการตอบสนองถัดไปอยู่ที่ใด

• ลดความหน่วงในการร้องขอครั้งถัดไป (ไม่ต้องมีการจับมือกันและไม่มีการเริ่มต้นที่ช้า )
• ลด การใช้งาน CPUและจำนวนรอบการรับส่งข้อมูล เนื่องจากมีการเชื่อมต่อใหม่และ การจับมือ TLS น้อย ลง
• เปิดใช้งาน การส่งข้อมูลแบบไปป์ไลน์ ของคำขอและการตอบกลับผ่าน HTTP
• ลดความแออัดของเครือข่าย ( จำนวนการเชื่อมต่อ TCP น้อยลง )
• สามารถรายงานข้อผิดพลาดได้โดยไม่ต้องปิดการเชื่อมต่อ TCP

ตามRFC 7230 มาตรา 6.4ระบุว่า "ไคลเอ็นต์ควรจำกัดจำนวนการเชื่อมต่อที่เปิดพร้อมกันที่รักษาไว้กับเซิร์ฟเวอร์ที่กำหนด" ข้อกำหนด HTTP/1.1 เวอร์ชันก่อนหน้าระบุค่าสูงสุดที่เฉพาะเจาะจงแต่ตามคำกล่าวของ RFC 7230 "พบว่าสิ่งนี้ไม่สามารถนำไปใช้ได้จริงสำหรับแอปพลิเคชันจำนวนมาก... ดังนั้น... ควรระมัดระวังเมื่อเปิดการเชื่อมต่อหลายรายการ" แนวทางเหล่านี้มีจุดประสงค์เพื่อปรับปรุงเวลาตอบสนองของ HTTP และหลีกเลี่ยงความแออัด หากมีการใช้งาน HTTP pipelining อย่างถูกต้อง จะไม่มีประโยชน์ด้านประสิทธิภาพใด ๆ ที่จะได้รับจากการเชื่อมต่อเพิ่มเติม ในขณะที่การเชื่อมต่อเพิ่มเติมอาจทำให้เกิดปัญหาความแออัด^{[ 14 ]}

หากไคลเอ็นต์ไม่ปิดการเชื่อมต่อเมื่อได้รับข้อมูลที่ต้องการครบถ้วนแล้ว ทรัพยากรที่จำเป็นในการรักษาการเชื่อมต่อบนเซิร์ฟเวอร์จะไม่สามารถใช้งานได้สำหรับไคลเอ็นต์รายอื่น ซึ่งจะส่งผลกระทบต่อทั้งความพร้อมใช้งานของเซิร์ฟเวอร์และความพร้อมใช้งานของทรัพยากรบนเซิร์ฟเวอร์ โดยระดับของผลกระทบจะขึ้นอยู่กับสถาปัตยกรรมและการกำหนดค่าของเซิร์ฟเวอร์

นอกจากนี้ ยัง อาจเกิด สภาวะการแข่งขัน (race condition)ขึ้นได้ โดยที่ไคลเอนต์ส่งคำขอไปยังเซิร์ฟเวอร์ในเวลาเดียวกันกับที่เซิร์ฟเวอร์ปิดการเชื่อมต่อ TCP ^{[ 15 ]}เซิร์ฟเวอร์ควรส่งรหัสสถานะ 408 Request Timeout ไปยังไคลเอนต์ทันทีก่อนที่จะปิดการเชื่อมต่อ เมื่อไคลเอนต์ได้รับรหัสสถานะ 408 หลังจากส่งคำขอแล้ว ไคลเอนต์อาจเปิดการเชื่อมต่อใหม่กับเซิร์ฟเวอร์และส่งคำขออีกครั้ง^{[ 16 ]} ไม่ใช่ว่าไคลเอนต์ทั้งหมดจะส่งคำขออีกครั้ง และหลายไคลเอนต์ที่ทำเช่นนั้นก็จะทำก็ต่อเมื่อคำขอมี วิธีการ HTTP ที่สามารถทำซ้ำได้ (idempotent HTTP method ) เท่านั้น

เว็บเบราว์เซอร์สมัยใหม่ทั้งหมด รวมถึงChrome , Edge , Firefox , Opera (ตั้งแต่เวอร์ชัน 4.0) ^{[ 17 ]}และSafariใช้การเชื่อมต่อแบบถาวร

ใน Firefox สามารถปรับแต่งจำนวนการเชื่อมต่อพร้อมกันได้ (ต่อเซิร์ฟเวอร์ ต่อพร็อกซี รวมทั้งหมด) การเชื่อมต่อแบบถาวรจะหมดเวลาหลังจากไม่มีการใช้งานเป็นเวลา 115 วินาที (1.92 นาที) ซึ่งสามารถเปลี่ยนแปลงได้ผ่านการกำหนดค่า^{[ 18 ]}

requestsไลบรารีของ Python ประกอบด้วย requests.Session()ซึ่งสร้างการเชื่อมต่อ HTTP แบบถาวร ทำให้สามารถนำการเชื่อมต่อ TCP พื้นฐานกลับมาใช้ใหม่ได้ ซึ่งอาจส่งผลให้ประสิทธิภาพเพิ่มขึ้นอย่างมาก^{[ 19 ]}

• การส่งข้อมูล แบบ HTTP pipeliningซึ่งช่วยให้สามารถส่งคำขอหลายรายการได้โดยไม่ต้องรอการตอบกลับ
• HTTP/2อนุญาตให้มีการประมวลผลคำขอและการตอบสนองแบบไม่เรียงลำดับ และยังสามารถส่งเนื้อหาล่วงหน้าก่อนที่จะมีการร้องขอได้ อีกด้วย

• โปรโตคอลการถ่ายโอนไฮเปอร์เท็กซ์ (HTTP/1.1): ไวยากรณ์ข้อความและการกำหนดเส้นทาง การจัดการการเชื่อมต่อ การคงอยู่ของข้อมูล
• พฤติกรรมการเชื่อมต่อแบบต่อเนื่องของเบราว์เซอร์ยอดนิยม (ข้อมูลเก่า)
• การสนับสนุนการรักษาการเชื่อมต่อ (Keep-Alive) ของ Apache HTTPD
• ผลกระทบต่อประสิทธิภาพเครือข่ายของ HTTP/1.1, CSS1 และ PNG