상태 비 저장 인터넷 이해 [폐쇄]

데스크톱 개발자에서 웹 개발자로 전환하고 있는데 왜 HTTP가 stateless인지 이해하는 데 어려움을 겪고 있습니다. 그 이유는 무엇입니까? 나 같은 데스크톱 개발자가 상태 비 저장 개발 환경으로 전환 할 수있는 방법에는 어떤 것이 있습니까?

이것은 내가 본 상태 비 저장 인터넷에 대한 가장 좋은 설명입니다.

 아내에게 REST 를 설명하는 방법
http://www.looah.com/source/view/2284

부인 : Roy Fielding은 누구입니까?

라이언 : 어떤 사람. 그는 똑똑하다.

부인 : 오? 그가 무슨 짓을 한거야?

Ryan : 그는 첫 번째 웹 서버를 작성하는 데 도움을 주었고 웹이 왜 그렇게 작동하는지 설명하는 수많은 연구를 수행했습니다. 그의 이름은 서버에서 브라우저로 페이지를 가져 오는 데 사용되는 프로토콜 사양에 있습니다.

부인 : 어떻게 작동합니까?

라이언 : 웹?

부인 : 네.

라이언 : 흠. 글쎄, 정말 정말 놀랍습니다. 그리고 재미있는 점은 모두 매우 저평가 된 것입니다. 내가 말한 프로토콜, HTTP는 사람들이 어떤 이유로 든 무시하는 모든 종류의 깔끔한 것들을 할 수 있습니다.

부인 : 브라우저에 입력하는 것의 시작과 같은 http를 의미합니까?

라이언 : 네. 첫 번째 부분은 사용할 프로토콜을 브라우저에 알려줍니다. 거기에 입력하는 것들이 컴퓨팅 역사상 가장 중요한 혁신 중 하나입니다.

부인 : 왜요?

Ryan : 전 세계 어디에서나 세계 어느 곳의 위치를 ​​설명 할 수 있기 때문입니다. 웹의 기초입니다. 지식과 정보를위한 GPS 좌표처럼 생각할 수 있습니다.

부인 : 웹 페이지?

라이언 : 정말. 로이 필딩 (Roy Fielding) 그 사람은 제가 그 연구에서 지적한 것들에 대해 많은 이야기를합니다. 웹은 REST라는 아키텍처 스타일을 기반으로합니다. REST는 리소스에 대한 정의를 제공합니다.

부인 : 웹 페이지는 자원입니까?

라이언 : 종류. 웹 페이지는 리소스를 나타냅니다. 리소스는 개념 일뿐입니다. URL-- 브라우저에 입력하는 것 ...

부인 : URL이 뭔지 알아요 ..

라이언 : 아, 맞습니다. 그들은 어딘가에 개념이 있다고 브라우저에 알려줍니다. 그런 다음 브라우저는 개념의 특정 표현을 요구할 수 있습니다. 구체적으로, 브라우저는 개념의 웹 페이지 표현을 요구합니다.

부인 : 다른 어떤 표현이 있습니까?

Ryan : 사실, 표현은 많이 사용되지 않는 것들 중 하나입니다. 대부분의 경우 리소스에는 단일 표현 만 있습니다. 그러나 우리는 표현이 앞으로 더 많이 사용될 것으로 기대하고 있습니다.

부인 : 뭐처럼?

라이언 : 흠. 사람들이 웹 서비스를 호출한다는 개념이 있습니다. 그것은 많은 다른 사람들에게 많은 다른 것을 의미하지만 기본 개념은 사람들이하는 것처럼 기계가 웹을 사용할 수 있다는 것입니다.

부인 : 이것은 또 다른 로봇입니까?

라이언 : 아뇨. 기계가 책상에 앉아 웹을 탐색한다는 의미는 아닙니다. 그러나 컴퓨터는 동일한 프로토콜을 사용하여 서로 메시지를주고받을 수 있습니다. 우리는 오랫동안 그렇게 해왔지만 오늘날 우리가 사용하는 기술 중 어느 것도 전 세계의 모든 기계와 대화 할 수있을 때 잘 작동하지 않습니다.

부인 : 왜 안돼?

Ryan : 그런 식으로 설계되지 않았기 때문입니다. 필딩과 그의 친구들이 웹을 구축하기 시작했을 때, 세계 어느 곳에서나 어떤 기계와도 대화 할 수있는 것이 가장 큰 관심사였습니다. 직장에서 컴퓨터가 서로 대화하도록하는 데 사용하는 대부분의 기술에는 이러한 요구 사항이 없었습니다. 작은 기계 그룹과 대화하기 만하면됩니다.

부인 : 이제 모든 기계들과 대화해야합니까?

Ryan : 예. 그 이상입니다. 다른 모든 머신에있는 모든 것들에 대해 모든 머신과 대화 할 수 있어야합니다. 따라서 한 시스템이 다른 시스템에 다른 시스템에있을 수있는 자원에 대해 알리는 방법이 필요합니다.

부인 : 무엇?

Ryan : 언니와 이야기하고 있는데 스위퍼 나 물건을 빌리고 싶다고 가정 해 봅시다. 그러나 당신은 그것을 가지고 있지 않습니다-당신의 엄마는 그것을 가지고 있습니다. 그래서 당신은 당신의 여동생에게 대신 엄마에게 가져 가라고 말합니다. 이것은 실제 생활에서 항상 발생하며 기계가 대화를 시작할 때 항상 발생합니다.

부인 : 그러면 기계들은 서로가 어디에 있는지 어떻게 알 수 있습니까?

Ryan : 물론 URL입니다. 기계가 말해야 할 모든 것이 해당 URL을 가지고 있다면, 명사와 동등한 기계를 작성한 것입니다. 당신과 나 그리고 세계의 다른 사람들이 명사에 대해 특정 방식으로 이야기하는 것에 동의했다는 것은 매우 중요합니다.

부인 : 네.

Ryan : 기계는 보편적 인 명사를 가지고 있지 않습니다. 모든 프로그래밍 언어, 데이터베이스 또는 다른 종류의 시스템은 명사에 대해 다른 방식으로 이야기합니다. URL이 매우 중요한 이유입니다. 이 모든 시스템이 서로의 명사에 대해 서로에게 알려주도록하겠습니다.

부인 : 그러나 웹 페이지를 볼 때, 나는 그렇게 생각하지 않습니다.

Ryan : 아무도 없습니다. Fielding과 소수의 다른 사람들을 제외하고. 그래서 기계가 여전히 빨라집니다.

부인 : 동사와 대명사, 형용사는 어떻습니까?

Ryan : REST의 또 다른 큰 측면이기 때문에 재미있었습니다. 어쨌든 동사는

부인 : 그냥 농담 이었어요.

Ryan : 재밌는 농담 이었지만 실제로는 전혀 농담이 아닙니다. 동사가 중요합니다. 프로그래밍과 다형성이라는 CS 이론에는 강력한 개념이 있습니다. 그것은 다른 명사들이 같은 동사를 적용 할 수 있다고 말하는 괴짜 방법입니다.

부인 : 나는 그것을 얻지 못한다.

Ryan : 음 .. 커피 테이블 좀 봐. 명사 란 무엇입니까? 컵, 트레이, 신문, 리모컨. 자,이 모든 것들에 대해 당신이 할 수있는 일은 무엇입니까?

부인 : 나는 그것을 얻지 못한다 ...

Ryan : 알 겠어요? 당신은 그들을 선택할 수 있습니다. 당신은 그들을 넘어 뜨릴 수 있습니다. 화상을 입을 수 있습니다. 동일한 동사를 거기에있는 모든 물체에 적용 할 수 있습니다.

부인 : 알았어 ... 그래?

Ryan : 글쎄요. 내가 대신 "컵을 마시고", "신문을 받고", "원격을 얻는다"고 말할 수 있다면 어떨까요? 대신 각 명사마다 다른 동사를 생각해 내야한다면 어떨까요? 나는 "get"이라는 단어를 보편적으로 사용할 수 없었지만 대신 각 동사 / 명사 조합에 대해 새로운 단어를 생각해야했습니다.

부인 :와 ! 이상 하네.

Ryan : 그렇습니다. 우리의 두뇌는 같은 동사가 많은 다른 명사에 적용될 수 있다는 것을 알기에 충분히 영리합니다. 일부 동사는 다른 동사보다 더 구체적이며 작은 명사에만 적용됩니다. 예를 들어, 나는 컵을 운전할 수없고 차를 마실 수 없습니다. 그러나 일부 동사는 GET, PUT 및 DELETE와 같이 거의 보편적입니다.

부인 : 컵을 삭제할 수 없습니다.

Ryan : 알겠습니다. 하지만 버릴 수 있습니다. 또 다른 농담 이었어요?

부인 : 네.

Ryan : 어쨌든 HTTP (이 Fielding과 그의 친구들이 만든 프로토콜)는 명사에 동사를 적용하는 것입니다. 예를 들어, 웹 페이지로 이동하면 브라우저가 입력 한 URL에서 HTTP GET을 수행하고 웹 페이지가 다시 제공됩니다.

웹 페이지에는 보통 이미지가 있습니다. 그것들은 별개의 자원입니다. 웹 페이지는 이미지의 URL을 지정하기 만하면 브라우저는 모든 리소스를 얻고 웹 페이지가 표시 될 때까지 더 많은 HTTP GET을 수행합니다. 그러나 여기서 중요한 것은 매우 다른 종류의 명사를 동일하게 취급 할 수 있다는 것입니다. 명사가 이미지, 텍스트, 비디오, mp3, 슬라이드 쇼인지 여부 URL이 주어진 것과 같은 방식으로 모든 것을 얻을 수 있습니다.

부인 : GET은 매우 중요한 동사 인 것 같습니다.

라이언 : 그렇습니다 . 특히 웹 브라우저를 사용하는 경우 브라우저는 거의 GET 항목이기 때문에. 그들은 리소스와 다른 많은 유형의 상호 작용을하지 않습니다. 이것은 많은 사람들이 HTTP가 GETing을위한 것이라고 가정하게했기 때문에 문제가됩니다. 그러나 HTTP는 실제로 동사를 명사에 적용하기위한 범용 프로토콜입니다.

부인 : 멋지다. 그러나 여전히 이것이 어떻게 바뀌는 지 알지 못합니다. 어떤 종류의 명사와 동사를 원하십니까?

Ryan : 명사들이 있지만 올바른 형식은 아닙니다.

amazon.com을 탐색 할 때 크리스마스를 위해 나를 사야 할 것들을 찾으십시오. 각 제품이 명사라고 상상해보십시오. 이제 기계가 이해할 수있는 표현으로 사용 가능하다면 많은 깔끔한 일을 할 수 있습니다.

부인 : 왜 기계가 일반 웹 페이지를 이해할 수 없습니까?

Ryan : 웹 페이지는 사람들이 이해하도록 설계 되었기 때문입니다. 기계는 레이아웃과 스타일을 신경 쓰지 않습니다. 기계는 기본적으로 데이터 만 필요합니다. 이상적으로 모든 URL은 사람이 읽을 수 있고 기계가 읽을 수있는 표현을 갖습니다. 기계가 자원을 얻으면 기계가 읽을 수있는 기계를 요구합니다. 브라우저가 사람을위한 리소스를 얻으면 사람이 읽을 수있는 것을 요청합니다.

부인 : 그래서 사람들은 모든 페이지에 대해 기계 형식을 만들어야합니까?

Ryan : 가치가 있다면.

우리는 이것에 대해 많은 추상화로 이야기하고 있습니다. 실제 사례를 보자. 당신은 교사입니다-학교에서 나는 당신이 학생들을 관리 할 수 ​​있도록 큰 컴퓨터 시스템, 또는 3-4 개의 컴퓨터 시스템을 가지고있을 것입니다. 시스템이 웹 기반 인 경우 여기에 관련된 각 명사 (예 : 학생, 교사, 수업, 책, 방 등)에 대한 URL이있을 수 있습니다. 브라우저는 웹 페이지를 제공합니다. 각 URL에 대해 기계가 읽을 수있는 표현이 있다면, 모든 정보가 표준 방식으로 소비 될 수 있기 때문에 새로운 도구를 시스템에 래치하는 것은 쉽지 않습니다. 또한 각 시스템이 서로 대화하기가 훨씬 쉬워집니다. 또는 각 개별 학교 시스템과 대화하여 시험 점수를 수집 할 수있는 주 또는 전국 시스템을 구축 할 수 있습니다. 가능성은 끝이 없습니다.

각 시스템은 간단한 HTTP GET을 사용하여 서로 정보를 얻습니다. 한 시스템이 다른 시스템에 무언가를 추가해야하는 경우 HTTP POST를 사용합니다. 시스템이 다른 시스템에서 무언가를 업데이트하려면 HTTP PUT을 사용합니다. 알아 내야 할 유일한 것은 데이터의 모습입니다.

부인 : 이것이 당신과 모든 컴퓨터 사람들이 지금 일하고있는 것입니까? 데이터의 모양을 결정 하시겠습니까?

라이언 : 슬프게도. 대신, 대다수는 거의 유용하지 못하고 다른 방식으로이 작업을 수행하기 위해 복잡한 사양의 계층을 작성하는 데 바쁩니다. 명사는 보편적이지 않고 동사는 다형성이 아닙니다. 우리는 수십 년의 실제 현장 사용과 입증 된 기술을 버리고 과거에 실패한 다른 시스템과 매우 유사한 것으로 시작합니다. 우리는 HTTP를 사용하고 있지만 네트워크 및 보안 담당자와의 대화에 덜 도움이되기 때문입니다. 우리는 화려한 도구와 마법사를 위해 단순성을 거래하고 있습니다.

부인 : 왜요?

Ryan : 잘 모르겠습니다.

부인 : 왜 말하지 않습니까?

Ryan : 어쩌면 내가 할 것입니다.

수십억 억의 연결 상태를 저장하는 것이 어떻게 가능하다고 생각하십니까? :) 따라서 필요한 경우에만 세션에 상태를 저장하십시오.

BTW : HTTP는 연결이 없습니다.

데스크탑 개발자는 풍부한 UI 경험에 더 익숙 할 것입니다. 웹으로 이동하면 한 발짝 물러 설 수 있습니다. 웹 세계에서는 창의성이 자유롭지 않으며 제약을 줄 수 있습니다. 당신을 실망시키지 마십시오! 전환을 도울 수있는 많은 것들이 있으며 여기에 짧은 목록이 있습니다.

1. 상태는 공유 될 수 있지만 서버에서 자주 유지되며 세션 ID, URL 매개 변수, 숨겨진 필드 또는 쿠키 값과 같은 토큰을 사용하여 참조됩니다.
2. 상태 비 저장 모델은 트랜잭션 처리에 적합합니다. 필요한 상태의 양을 줄일 수있는 방식으로 모델을 빌드하십시오. 트랜잭션 처리 의 ACID 원칙은이를 달성하는 데 도움이 될 수 있습니다.
3. MVC 패턴에 익숙해 지십시오 (아직없는 경우). 이것은 분리 된 관심을 유지함으로써 설계를 개선하는 데 도움이됩니다. Struts (Java) 및 MVC (.NET) 와 같은 인기있는 프레임 워크 가이 개념을 기반으로 구축되었습니다.
4. 풍부한 UI 경험을 위해 Java , Flash 또는 Silverlight 와 같은 플러그인을 사용해보십시오 . 풍부한 경험을 위해서는 JQuery 또는 AJAX 와 같은 널리 사용되는 Java 스크립트 기반 라이브러리를 사용하십시오 .

행복한 프로그래밍!

수백만 개의 웹 페이지가 없었던 시간이 있었기 때문입니다. 대학과 연구 시설에만 몇 페이지가있는 시간이 있었기 때문입니다. 광대역이 없었던 때가 있었고, http는 탁상 전화기 위에있는 1200 개의 보우 모뎀과 통신했습니다. "리치 웹 앱"이보기에는 엄청나게 많은 대역폭이 필요할 때가있었습니다. 초기 인터넷은 매우 신뢰할 수 없었기 때문에 TCP / IP가 생성되었음을 기억하십시오.

HTTP 1.0은 1990 년대 초에 존재했습니다. 당시의 인터넷은 어땠는지, 왜 그렇게 인터넷을 디자인했는지 생각해보십시오.

모든 것이 진화했습니다. 인터넷은 웹 브라우저와 웹 이전에 존재했습니다. 그것은 ftp, telnet, gopher, ping, finger 및 몇 가지 다른 비트와 밥의 버블 링 냄비였습니다. 첫 번째 웹 브라우저 인 Mosaic (오래된 것은 1991 년에 대학에 있었다고 생각합니다)은 ftp와 문서 뷰어 사이의 일종의 혼란으로 작용했습니다. 마법은 문서에 새 문서를 ftp로 연결하는 링크를 가질 수 있다는 점에서 발생했습니다.

우리는 이제 20 년 동안 진화했습니다. 행복한 진화는 아니었다. 우리는 브라우저 전쟁을 겪었고 IE와 Netscape는 표준 제어 (Bit of the simplification;)를 위해 그것을 제거했으며, 다양한 다른 업체들이 풍부한 컨텐츠를 허용하기 위해 플러그인을 도입하기 시작했습니다. 자바는 마법의 총알이자 플래시였습니다. 3D 세계를 약속하고 스타 워즈 모델의 정확히 6 개 3D 모델을 제공 한 VRML 플러그인을 기억하는 사람이 있습니까?

나는 끝을 향해 조금 나아 갔지만, 당신은 아이디어를 얻는다 :)

주요 이유는 acedemia가 HTTP의 목적을 믿었던 것과 확장 성의 이유로 조합 된 것과 관련이 있습니다. HTML은 원래 학계의 경계를 넘어 정보 또는 논문을 공유하도록 설계되었습니다. 순전히 양식화 된 텍스트였습니다. 사람들이 그 모델 이상으로 생각하기 시작한 사진을 제공하기 위해 첫 번째 브라우저를 사용하기 전까지는 아니 었습니다.

다음 고려 사항은 무국적 결정을 강화했습니다.

• 일반적인 상호 작용은 빠른 다운로드 및 읽기가 될 것입니다. 다음 요청까지의 지연 동안 소켓은 유휴 상태가됩니다.
• 소켓은 귀중한 시스템 리소스를 사용합니다. SMTP와 마찬가지로 대화를 유지할 필요가 없다면 한 대의 컴퓨터가 수천 명의 클라이언트를 처리하도록 많은 작업을 수행 할 수 있습니다.
• 이들은 이미 원격 셸 계정, NFS, SMTP 및 기타 상태 저장 연결 프로토콜 관리를 통해 귀중한 교훈을 얻었습니다.

웹 페이지가 더욱 복잡해지고 많은 그래픽과 스타일 시트가 포함되면서 HTTP는 "keep-alive"플래그로 수정되었습니다. 그러면 소켓이 작동하고 클라이언트가 동일한 대화로 여러 리소스를 요청할 수 있습니다.

현재 인터넷 사용 모델을 고려하면 원래 결정은 여전히 ​​유효합니다. 때때로 불편할 수 있지만 서버와의 소규모의 양자화 된 상호 작용은 유휴 소켓보다 확장 성이 뛰어납니다.

양방향 브라우저를 의미하는 경우.

보안 이유.

예를 들어 SPAM!

웹에서 다음 단계로 양방향 통신

그렇지 않으면 인터넷은 TCP / IP (2 개의 프로토콜) 및 UDP를 실행합니다.

전송 제어 프로토콜(TCP)는 Internet Protocol Suite의 핵심 프로토콜 중 하나입니다. TCP는 인터넷 프로토콜 (IP)을 보완하는 제품군의 두 원래 구성 요소 중 하나이므로 전체 제품군을 일반적으로 TCP / IP라고합니다. TCP는 동일한 네트워크의 두 호스트간에 데이터를 직접 교환하는 서비스를 제공하는 반면, IP는 하나 이상의 네트워크에서 주소 지정 및 라우팅 메시지를 처리합니다. 특히 TCP는 한 컴퓨터의 프로그램에서 다른 컴퓨터의 다른 프로그램으로 바이트 스트림을 안정적으로 순서대로 전달합니다. TCP는 주요 인터넷 응용 프로그램, 월드 와이드 웹, 전자 메일 및 파일 전송과 같은 응용 프로그램에 의존하는 프로토콜입니다. 안정적인 데이터 스트림 서비스가 필요하지 않은 다른 응용 프로그램,

인터넷 프로토콜(IP)는 Internet Protocol Suite를 사용하여 인터 네트워크에서 데이터 그램 (패킷)을 릴레이하는 데 사용되는 주요 통신 프로토콜입니다. 네트워크 경계를 통해 패킷을 라우팅하는 것은 인터넷을 설정하는 기본 프로토콜입니다. IP는 Internet Protocol Suite의 인터넷 계층의 기본 프로토콜이며 주소에 따라 소스 호스트에서 대상 호스트로 데이터 그램을 전달하는 작업을 수행합니다. 이를 위해 IP는 데이터 그램 캡슐화를위한 주소 지정 방법과 구조를 정의합니다. 역사적으로 IP는 1974 년 Vint Cerf와 Bob Kahn이 도입 한 최초의 전송 제어 프로그램에서 연결없는 데이터 그램 서비스였으며, 다른 하나는 연결 지향 전송 제어 프로토콜 (TCP)입니다. 따라서 Internet Protocol Suite는 종종 TCP / IP라고합니다.

데스크톱 응용 프로그램에서 사용자는 정의 된 시작 및 종료와 함께 일련의 작업을 수행하는 것으로 가정합니다. 이러한 응용 프로그램에서는 사용자가 서버가 데이터를 제공하는 모든 서버에 로그인하고 완료 될 때까지 로그인 상태를 유지하는 것이 좋습니다.

웹 상호 작용은 (일반적으로) 동일한 모델을 따르지 않습니다. 예를 들어, 전자 상거래 사이트에서 사용자는 Google 검색의 결과로 제품 설명에 도착한 후 즉시 해당 페이지를 떠나 다른 제품이 동일한 제품을 제공하는 것을 볼 수 있습니다. 또는 체크 아웃 프로세스를 시작한 다음 제품이 너무 비싸다고 판단하여 반쯤 포기할 수 있습니다. "하이퍼 텍스트"의 기본 개념은 한 위치에서 다른 위치로 이동할 수있는 능력과 기대를 의미합니다.

영구 연결은 리소스를 소비합니다. 아마도 네트워크 소켓 일 수도 있고, 구문 분석 된 데이터베이스 쿼리 풀일 수도 있습니다. 그것은 모두 응용 프로그램에 따라 다릅니다. 언제든지 사라질 수있는 사용자를 고려할 때 이러한 리소스를 계속 커밋하는 것은 이치에 맞지 않습니다.

실제로 사용자가 영구적으로 연결할 필요는 없습니다. 웹 응용 프로그램은 필요한 모든 리소스 (예 : 데이터베이스)에 대한 연결을 유지 관리하고 모든 사용자 요청간에 공유합니다. 웹 응용 프로그램 프레임 워크는 세션을 제공합니다. 세션은 서로 다른 요청에 대해 사용자 별 데이터를 저장하는 시간 제한적인 장소입니다. (쉽게) 할 수없는 유일한 일은 클라이언트 제어 트랜잭션을 오래 실행하는 것입니다. 그러나 연결을 유지하는 앱에서도 나쁜 생각입니다.

인터넷이 반드시 상태 비 저장 상태 일 필요는 없으며 실제로 Java EE를 볼 때 상태 저장 EJB 및 상태 비 저장 EJB가 있습니다.

개발자가 상태 비 저장 아키텍처 사용을 권장하는 주된 이유는 확장 성 때문입니다. 트래픽을 지원하기 위해 서버를 추가 및 삭제 한 후에 모든 사용자의 상태를 유지하려고한다고 상상해보십시오.

상태 비 저장 아키텍처를 개발하는 것은 어렵지 않습니다. 요점은 가능한 한 적은 상태 (보통 사용자 ID-바람직하게는 쿠키에 있음)를 유지하고 필요에 따라 데이터베이스를 변경하는 것입니다.

나는 그것이 그런 식으로 시작하고 계속 그런 식으로 생각합니다. 주변에 너무 많은 인프라가 구축되었으므로 변경할 수 없습니다.

처음에는 연결의 안정성이 떨어지고 대역폭이 작기 때문에 상태 비 저장 상태로 시작되었을 수 있습니다. 활성 연결이 많지 않으면 더 많은 트래픽을보다 쉽게 ​​처리 할 수 ​​있습니다.

더 나은 정보가 있거나 더 나은 답변이 있으면 수정하거나 의견을 남겨주세요.

서버 가 서비스를 제공 하기 때문입니다 (이름). 요청을하고 답변을 받으십시오.

웹 개발로 전환하는 것과 관련하여 ASP.NET Web Forms가 더 이해하기 쉬운 방식으로이 작업을 수행 할 것이라고 생각합니다. 그러나 이는 추상화 계층에서 실제로 발생하는 작업을 숨기기 때문입니다.

HTTP (HyperText Transfer Protocol)의 이름을 분석하면 많은 것을 이해할 수 있습니다. 풍부한 UI 프로토콜로 설계되지 않았습니다. 원래 아이디어는 문서를 링크로 공유하는 것이 었습니다. 문서를 요청하면 해당 문서의 사본으로 회신합니다.

원래 HTTP에는 하나의 동사 GET 만있었습니다. 이와 관련하여 정적 콘텐츠를 위해 설계되었습니다. 누군가가 공유하는 문서를 요청할 때 왜 상태가 필요한가? 그렇기 때문에 HTTP의 출처가 없기 때문에 HTTP가 상태가없는 이유입니다.