HTTP
Socket 부터 타고타고 들어가서
HTTP 부터 살펴보려고 한다.
메서드 | 설명 | request body |
successful response body |
안전 | 멱등 | 캐시 가능 | allow in HTML forms |
GET | 리소스 요청 | NO | YES | YES | YES | YES | YES |
HEAD | GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함 X | NO | NO | YES | YES | YES | NO |
POST | 내용 전송 | YES | YES | NO | NO | NO | YES |
PUT | 내용 갱신 | YES | YES | NO | YES | NO | NO |
DELETE | 리소스를 삭제 | 권장하지 않으나 가능 | 권장하지 않으나 가능 | NO | YES | NO | NO |
CONNECT | 목적 리소스로 식별되는 서버로의 터널을 맺음 | NO | YES | NO | NO | NO | NO |
OPTIONS | 웹 서버측 제공 메소드에 대한 질의 | NO | YES | YES | YES | NO | NO |
TRACE | 목적 리소스의 경로를 따라 메시지 loop-back 테스트 | NO | YES | NO | YES | NO | NO |
PATCH | 내용 부분 갱신 | YES | YES | NO | NO | NO | NO |
🌐 HTTP는 무엇일까요? - 기본 핵심 요약 총정리
HTTP 란? - Hyper Text Transfer Protocol HTTP는 서버와 클라이언트가 서로 데이터를 주고받기 위해 사용되는 통신 규약을 말일컷는다. 웹문서간에 링크를 통해 연결할 수 있는 프로토콜이며, 문서뿐 아니
inpa.tistory.com
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC
🌐 아주 쉽게 이해하는 Stateful / Stateless 차이
Stateful 과 Stateless 차이점 웹 공부를 하다보면 클라이언트(Client)와 서버(Server)간의 통신을 상태유지(Stateful) 하느냐, 상태유지하지않음(Stateless) 으로 하느냐 라는 말귀를 한번쯤은 들어본 적이 있
inpa.tistory.com
클라이언트와 서버 간의 상태 정보 유지 여부와 관련이 있다.
Stateful : 상태유지는
서버가 클라이언트의 상태 정보를 저장하는 방식
작동은 클라이언트의 이전 상태 정보를 기반으로 통신
-> 서버는 지속적으로 해당 상태 정보를 바탕으로 응답함.
ex) 로그인 유지 되는 웹페이지
문제점
-> 해당 서버 멈추거나 다른 서버 이용해야 하거나 하면은
갑자기 이전 상태값 다른 서버에서는 안 가지고 있음..
누구셈? 뭐임?
나이키에 전화를 했다.
불량 때문에 반품 문의를 했는데,
상담사에게 안내를 받고 15분 후에 다시 전화를 했다.
보통 서버에 상담기록이 저장이 되어서
나이키 고객 유선 상담 서비스는 기존 상담사 재연결은 불가능함.
(실제로 1년 정도 전에 그랬음)
근데 다시 전화 해도 전혀 모르는 상태로 전화를 받게 되는 것 같은 거임
"나이키닷컴 ~~~ 입니다. 무엇을 도와드릴까요?"
"상담사님 저 ~~~ 인데요, 제품 택 확인해봤고 택배를 어쩌구 저쩌구"
"네? ??????? 갑자기 그렇게 말씀하시면 제가 어케 앎?"
"??? 기록 없나요?"
"네.. 없는데여? 서버가 다르거든여 맨 처음부터 다시 말해주세요. 그리고 저희 규정은 이렇구요....
교환 시 반품 택배비.. 어쩌구 저쩌구.. "
라고 하는 상황 같은 거임
또는 클라이언트들을 처리할 한계치를 넘으면. = 너무 작업이 몰리면
한계치 만큼 처리 된 후에
그 다음 클라이언트의 작업 처리가 가능.
아무래도 서버에 무리가 될 수 있다.
Stateless : 무상태
서버가 클라이언트의 상태 정보를 저장하지 않는 방식
클라이언트의 요청마다 모든 필요 정보 독립적으로 처리, 각 요청 간 상태 정보 유지되지 않음.
ex) HTTP 통신 기본
상태관리는 클라이언트가 알아서 하라는 거임.
단순하게 받아서 응답만 해줌. 서버에 상태 유지에 대한 부하가 현저히 줄어든다.
문제점
-> 클라이언트 요청에 상대적으로 더 많은 데이터가 소모되게 됨 (상태 유지 방식에 비해)
유저 로그인 같은 부분은 계속 로그인이 풀리면 불편하기 때문에
부분적으로 사용하는 것이 베스트이다.
HTTP 통신은
클라이언트(프론트) 와 서버(백엔드)로 나뉘어진 구조로 되어있다.
사실 요청 없는 응답은 없다
TCP ?
전송 제어 프로토콜 Transmission Control Protocol, TCP
OSI 기본 참조 모델을 기준으로 제4계층(전송 계층)에 해당되는 프로토콜.
인터넷 프로토콜(IP)과 함께 TCP/IP를 구성하고 있다.
패킷의 도착 순서대로 배열이나 오류 수정 등이 행해지므로
전송 제어 프로토콜(TCP)보다 상위층에서 보았을 때는 2대의 컴퓨터가 신뢰성이 높은 전용선으로 연결된 것 같이 보인다.
TTA정보통신용어사전
한국정보통신기술협회(TTA)는 정보통신 기술 발전과 타 분야와의 기술 융합에 따라 무수히 생성되는 정보통신용어를 해설하고 표준화하여, 전문가뿐만 아니라 비전문가들도 올바르게 활용할 수
terms.tta.or.kr
소켓이 등장한 간단한 순서
HTTP 에서
사용자는 서버로부터 새로운 정보를 받아보기 위해서,
반드시 새로운 URL을 요청해야 한다
= 새로고침 해야 한다.
그래서 AJAX 가 나왔다.
AJAX : Asynchronous Javascript And Xml의 약자
비동기적인) 자바스크립트로 DOM을 읽고 쓰며,XML Http Request 객체를 통해 서버와 데이터를 주고받기 때문에 명명
DOM : Document Object Model
XML : https://www.w3schools.com/xml/xml_syntax.asp
XML Syntax
W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.
www.w3schools.com
longpolling 같은 것도 나왔다.
- 주기적으로 요청하여 결과를 확인하는 방식
- 요청 주기가 짧아지게 되면 서버에 부담이 커지게 됨
- 반대로 주기가 길면 실시간 성능이 떨어지게 됨
그래서 HTML 5에서 Web Socket이 나오게 되었다.
웹 소켓을 통한 TCP 통신의 확장은
브라우저와 서버 간의 통신에서 TCP의 장점을 활용하게 설계 되었다.
TCP의 역할과 특징: 데이터의 안정적이고 순차적인 전송을 보장
웹소켓은 한 번의 연결 설정으로 지속적인 데이터 교환을 가능하게 하며,
이는 TCP가 제공하는 신뢰성 있는 연결기반 위에서 이뤄진다.
그래서 HTTP 대비해서 이점으로는 비연결성을 해결하게 되었고
실시간 통신이 가능하게 되었다.
그러나....
HTML5 기술이라서
오래된 버전의 웹 브라우저에 지원을 안하는 등의 문제가 있어서
이를 해결하기 위해서 나타난 것이
Socket.IO
Socket.io는 node.js 기반으로 만들어진 기술로,
거의 모든 웹 브라우저와 모바일 장치를 지원하는 실시간 웹 애플리케이션 지원 라이브러리이다.
Socket.io는 웹 브라우저와 웹 서버의 종류와 버전을 파악하여
가장 적합한 기술을 선택하여 사용한다.
만약 브라우저에 FlashSocket이라는 기술을 지원하는 플러그인이 설치되어 있으면
그것을 사용하고 플러그인이 없으면 AJAX Long Polling 방식을 사용하도록 한다..
이것은 100% 자바스크립트로 구현되어 있으며,
현존하는 대부분의 실시간 웹 기술들을 추상화해 놓았다.
웹 소켓은 서버에서도 클라이언트를 인지하는 상태이기에
양방향 통신이 가능하다.