Làm thế nào để HTTP trở thành không quốc tịch?

26

HTTP được cho là không trạng thái. Có nghĩa là, nó không cần lưu trữ thông tin để truyền dữ liệu.

Nhưng HTTP sử dụng TCP, được định hướng theo trạng thái.

Nếu đó là trường hợp, làm thế nào để HTTP trở nên không trạng thái?

networking tcp web

— Kiến
nguồn

6

Làm thế nào đây không phải là một bản sao 5 năm sau khi Super User được ra mắt?

— Peter Mortensen

Bởi vì hầu hết các bản sao đều có trên StackOverflow? Tôi chỉ đang đoán thôi.

— phân tích

8

Chỉ vì nó chạy qua dây cáp (trong số những thứ khác), cũng không biến nó thành một giao thức điện

— Hagen von Eitzen

stackoverflow.com/questions/13200152/ cường

— Ali786

42

HTTP không quan tâm đến tập tin và không phụ thuộc vào bất kỳ giao thức cấp thấp nào được sử dụng để tự vận chuyển, mặc dù bản thân nó không trạng thái.

Công nghệ vận chuyển có thể là TCP, hoặc SPX cũ của Novell hoặc SCTP hoặc bất cứ điều gì khác mà bạn có thể mơ ước và HTTP vẫn sẽ hoạt động như nhau. HTTP không yêu cầu giao thức truyền phát trực tiếp hoặc hướng kết nối, và phụ thuộc vào các URL có thể phân giải được nhưng không quan tâm đến việc đó được thực hiện như thế nào.

Đây là một trong những lý do tại sao mô hình lớp hoặc ngăn xếp mạng tồn tại: Lớp ứng dụng không cần phải quan tâm đến các lớp thấp hơn.

Chỉ vì một giao thức cấp thấp hơn là trạng thái không có nghĩa là bất cứ thứ gì trên đầu nó tự động trở thành trạng thái hoặc được yêu cầu phải có trạng thái.

Bản thân HTTP là không trạng thái. Vì vậy, điều đó có nghĩa là các ứng dụng phải triển khai một lớp khác trên HTTP để thiết lập trạng thái. Điều này thường được thực hiện với cookie phiên.

— LawrenceC
nguồn

1

Định tuyến xảy ra ở cấp độ tcp / ip.

— Phòng thí nghiệm Fiasco

3

Hình ảnh này giải thích nó độc đáo. vichargrave.com/wp-content/uploads/2013/01/ từ

— JakeGould

2

Thật trùng hợp, việc HTTP bỏ qua trạng thái của kết nối cơ bản (mà hầu như sẽ luôn là TCP) là một trong những thiếu sót lớn về hiệu năng mà các cách tiếp cận HTTP2 khác nhau đang cố gắng giải quyết.

— skolima

2

@Fiasco: Nói đúng ra, việc định tuyến xảy ra ở cấp IP. Định tuyến dựa trên Địa chỉ Internet, không có thông tin nào từ lớp TCP được sử dụng trong định tuyến cơ bản.

— RedGrittyBrick

1

@skolima: mặt khác, trạng thái không trạng thái là lý do tại sao HTTP là giao thức có khả năng mở rộng và đáng tin cậy nhất được sử dụng rộng rãi. HTTP luôn được thiết kế rõ ràng cho khả năng mở rộng thay vì hiệu năng (vâng, chúng là điều khác biệt), vì vậy nếu bạn nghĩ rằng bạn cần độ trễ thấp khó khăn hơn là bạn đang sử dụng giao thức sai hoặc bạn đang sử dụng giao thức không chính xác. Mặc dù HTTP2 có ý định cải thiện hiệu suất, nhưng nó thực hiện theo cách vẫn đúng với trạng thái không trạng thái. Khi được sử dụng cho mục đích của nó, tôi chưa bao giờ thấy trạng thái không trạng thái là một nút cổ chai của một ứng dụng HTTP được thiết kế tốt.

— Lie Ryan

10

"HTTP là không trạng thái" có nghĩa là mỗi giao dịch HTTP (cặp phản hồi yêu cầu) có thể được xử lý độc lập với bất kỳ trạng thái nào từ cặp phản hồi yêu cầu trước đó.

Để vận chuyển cặp đáp ứng yêu cầu cụ thể, bạn cần một giao thức có thể mang khối lớn tùy ý ở đó và khối lớn tùy ý trở lại, và để thực hiện điều đó trên một lớp có kích thước gói hạn chế, TCP phải có trạng thái.

Nhưng qua ranh giới giao dịch, không có nhà nước. Máy khách có thể hủy kết nối và thiết lập kết nối mới cho yêu cầu tiếp theo. Trong thực tế, đó là tùy chọn duy nhất trong các phiên bản đầu và nó vẫn hoạt động như vậy nếu máy khách không bao gồm Connection: keep-alivetiêu đề.

Yêu cầu tiếp theo cũng có thể dễ dàng được xử lý bởi các máy chủ khác nhau và khách hàng sẽ không bao giờ biết, bởi vì máy chủ không cần duy trì bất kỳ trạng thái nào (trừ khi ứng dụng thêm trạng thái riêng của mình lên trên HTTP, thường là dưới dạng phiên; trong cân bằng tải là hình phạt của nó đối với việc xây dựng giao thức trạng thái trên HTTP). Điều đó được tận dụng trong các máy chủ bận rộn cân bằng tải.

— Jan Hudec
nguồn

can also easily be handled by different server and the client will never knowMặc dù về mặt kỹ thuật, điều này là sai lệch vì nhiều ứng dụng web sử dụng các phiên dính, yêu cầu bộ cân bằng tải để định tuyến các yêu cầu trong tương lai từ cùng một phiên duyệt đến cùng một máy chủ. Từ góc độ HTTP, các phiên không liên quan, nhưng loại câu cuối cùng của bạn ngụ ý rằng trải nghiệm của người dùng cuối sẽ không bị ảnh hưởng, điều này sẽ sai với các phiên dính.

— Brandon

1

@Brandon: Các ứng dụng như vậy xây dựng một giao thức trạng thái trên HTTP và đây là hình phạt của chúng dành cho nó!

— Jan Hudec

@Brandon: Rất nhiều máy chủ cân bằng tải, chẳng hạn như gmail, không gửi yêu cầu trở lại cùng một máy chủ. Thay vào đó, phiên được lưu trữ trong cơ sở dữ liệu dùng chung mà tất cả các máy chủ trong cụm có thể truy cập. Do đó, trạng thái không được xử lý bởi máy chủ mà bởi cơ sở dữ liệu.

— slebetman

@slebetman: Vâng, sao cũng được. Bản thân HTTP không có trạng thái như vậy, vì vậy đối với HTTP, nó đơn giản. Nếu ứng dụng thêm một số trạng thái của riêng nó, thì đó là cuộc chiến của nó.

— Jan Hudec

Phải, tôi đã không nói tất cả. Tôi nói một số. Cá nhân tôi thích tránh các phiên dính, và nếu có thể, tránh các phiên hoàn toàn. Tuy nhiên, phần mềm tồn tại không phù hợp với lý tưởng của mọi người.

— Brandon

2

Bản chất "không trạng thái" của HTTP có nghĩa là trên lớp này , không có thông tin trạng thái nào được tạo hoặc sử dụng.

Bạn có thể thấy điều này trong một vài trường hợp, ví dụ như trong xác thực HTTP, thông tin đăng nhập được gửi với mọi yêu cầu và các kết nối liên tục thực sự chỉ là một tối ưu hóa (tức là nếu tôi gửi thông tin đăng nhập, máy chủ sẽ quên những thông tin này sau khi yêu cầu, ngay cả khi nó rời đi kết nối mở).

Ngược lại, các cơ chế đăng nhập dựa trên cookie là trạng thái, nhưng không phải là một phần của HTTP.

— Simon Richter
nguồn

1

Bạn phải hiểu nó như một bộ búp bê Nga (hoặc hộp nếu bạn muốn) mỗi con mang một cái khác bên trong, đó là cách thức hoạt động của nó: TCP mang HTTP "bên trong" nhưng nó không quan tâm đến nó hoặc đó là các tính năng.

Để có được toàn bộ hình ảnh, tôi khuyên bạn nên đọc về Mô hình OSI vì nó làm cho nó rõ ràng hơn.

TCP nằm một vài lớp bên dưới HTTP trong mô hình OSI, mỗi lớp thực tế tương ứng với một giao thức khác nhau.

Trong trường hợp của chúng tôi, HTTP nằm trong lớp trình bày và ứng dụng và TCP trong lớp vận chuyển. Hoặc nếu bạn sử dụng Mô hình TCP / IP, cả giao thức TCP và IP đều nằm trong lớp Liên kết mạng và HTTP trong các lớp trình bày và ứng dụng.

— runlevel0
nguồn

1

Vấn đề với mô hình OSI là bây giờ chỉ là lý thuyết (đã có những nỗ lực thực tế để thực hiện nó, nhưng họ đã thất bại trên thị trường do sự phức tạp của chúng). Trong thực tế, không có lớp giữa TCP và HTTP. Ngoài ra, lớp trình bày sẽ là HTML, không phải HTTP.

— MSalters

Trong mô hình TCP / IP, TCP không sống trong lớp mạng. Nó sống trong lớp vận chuyển trên đỉnh IP, nằm trong mạng sau này. Lần truy cập google đầu tiên cho "mô hình TCP" minh chứng điều này: technet.microsoft.com/en-us/l Library / cc786900 (v = ws.10) .aspx

— Brandon

@MSalters: TLS không phải là một lớp?

— grawity

1

@MSalters: Bạn có nhận ra rằng HTTPS chỉ là tên được đặt bởi HTTP đang được TLS tạo đường hầm không? Vì TLS như vậy là một lớp trong HTTP và trên đầu của kết hợp TCP và TLS / SSL + HTTP được gọi là HTTPS.

— slebetman

1

Ngoài ra, còn có một tên mới cho combo TLS / HTTP. Nếu TLS mang lưu lượng HTTP thực hiện ghép kênh ổ cắm / luồng ảo thì nó được gọi là SPDY (nhưng url trong trình duyệt của bạn vẫn là HTTPS).

— slebetman