Notice
Recent Posts
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- JS typeof연산자
- JS 형변환
- JS 숫자
- JS null undefined
- JS appendChild
- JS value속성
- JS localStorage
- JS classList
- HTML기초
- JS setTimeout
- JS 삼항연산
- CSS기초
- JS prompt
- JS form action
- JS 연산
- JS 함수
- JS 데이터타입
- JS 스코프
- js 변수
- JS 기초
- JS 타이머기능
- JS 화살표함수
- git 협업셋팅
- JS clearInterval
- JS append
- JS form
- CSS속성정리
- JS preventDefault
- JS setInterval
- JS redirection
Archives
공부기록용
HTTP 웹 기본 지식(HTTP기본) 본문
🔻시작라인
HTTP(HyperText Transfer Protocol)
HTTP 메시지에 모든 것을 전송
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSON, XML (API)
- 거의 모든 형태의 데이터 전송 가능
- 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
기반 프로코톨
- TCP: HTTP/1.1, HTTP/2
- UDP: HTTP/3
- 현재 HTTP/1.1 주로 사용
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(스테이스리스), 비연결성
- HTTP 메시지를 통해서 통신
- 단순함, 확장 가능
클라이언트 서버 구조
- Request Response 구조
- 클라이언트는 서버에 요청을 보내고, 응답을 대기하고 서버가 요청에 대한 결과를 만들어서 응답
- 클라이언트와 서버의 개념적 분리가 중요, 각각의 독립적인 진화에 있어 중요한 부분이다.(각각 집중해야 하는 기능에 집중할 수 있다)
무상태 프로토콜(스테이스리스_stateless)
- 서버가 클라이언트의 상태를 보존X
- 무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능
- 장점 : 서버 확장성 높음(스케일 아웃_수평 확장에 유리)
- 단점 : 클라이언트가 추가 데이터 전송
- 한계 : 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
Stateful, Stateless 차이
|
Stateful(상태 유지) |
Stateless(무상태) |
클라이언트-서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미한다. 클라이언트의 이전 요청이 서버에 잘 전달되었을 때, 클라이언트의 다음 요청이 이전 요청과의 관계가 이어지는 것을 의미한다. |
클라이언트-서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미한다. Stateless 구조에서 server는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 세션 관리는 클라이언트에게 책임이 있다. 따라서 Stateless 구조는 클라이언트와의 세션 정보를 기억할 필요가 없으므로, 이러한 정보를 서버에 저장하지 않는다. 대신 필요에 따라 외부 DB에 저장하여 관리 할 수 있다. |
|
Example | TCP, FTP, Telnet | HTTP, UDP, DNS |
서버 필요성 |
서버, 세션을 저장하고 유지하려면 서버가 필요하다. | 서버, 세션정보를 저장할 서버가 필요없다. |
의존성 | 서버와 클라이언트가 밀접하게 결합되어 있다. | 서버와 클라이언트가 느슨하게 결합되어 있고 독립적으로 작동 할 수 있다. |
서버 디자인 |
서버 설계가 비교적으로 복잡하고 구현하기 어렵다. | 서버 설계가 간단하다. |
충돌 관리 | 서버가 세션 및 여러 세부 정보들을 유지해야 하기 때문에 어렵다. |
서버 장애가 발생해도, 충돌 후 다시 쉽게 시작이 가능하다. |
Transactions | 서버가 비교적 느리게 작동한다. | 서버에서 빠르게 처리할 수 있다. |
로그인 | 로그인이 필요 없는 단순한 서비스 소개 화면 |
비 연결성(connectionless)
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위의 이하의 빠른 속도로 응답
- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이 하로 매우 작음, 왜냐? 바로바로 끊어버리니깐 (ex. 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.)
- 서버 자원을 매우 효율적으로 사용할 수 있음
비 연결성의 한계와 극복
- 한계)연결을 끊다보니 다시 데이터를 보내려면 TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
- 한계)웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 등 수 많은 자원이 함께 다운로드
- 극복)지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
- 극복)HTTP/2, HTTP/3에서 더 많은 최적화
스테이스리스를 기억💫
같은 시간에 딱 맞추어 발생하는 대용량 트래픽 -> 수만명 동시 요청
HTTP 메시지
HTTP 메시지에 모든 것을 전송
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSON, XML
- 거의 모든 형태의 데이터 전송 가능
- 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
시작라인
요청 메시지
start-line = request-line / status-line
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
- HTTP 메서드 (GET: 조회)
- 요청 대상 (/search?q=hello&hl=ko)
- HTTP Version
💫요청 메시지 - HTTP 메서드
- 종류: GET, POST, PUT, DELETE...
- 서버가 수행해야 할 동작 지정
- GET: 리소스 조회 / POST: 요청 내역 처리
요청 메시지 - 요청 대상
- absolute-path[?query] (절대경로[?쿼리])
- 절대경로= "/" 로 시작하는 경로
- 참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다
요청 메시지 - HTTP 버전
- HTTP Version
응답 메시지
- start-line = request-line / status-line
- status-line = HTTP-version SP status-code SP reason-phrase CRLF
- HTTP 버전
💫HTTP 상태 코드: 요청 성공, 실패를 나타냄
200: 성공
400: 클라이언트 요청 오류
500: 서버 내부 오류
- 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글
HTTP 헤더
- header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
- field-name은 대소문자 구문 없음
용도
- HTTP 전송에 필요한 모든 부가정보(ex. 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보... 등 필요한 정보는 거의 있다고 보면 됨)
- 표준 헤더가 너무 많음 • https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
- 필요시 임의의 헤더 추가 가능 (helloworld: hihi)
HTTP 메시지 바디
- 실제 전송할 데이터
- HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
'📚강의록📚 > 인프런)HTTP' 카테고리의 다른 글
HTTP 웹 기본 지식(HTTP API 설계) (0) | 2023.07.24 |
---|---|
HTTP 웹 기본 지식(클라이언트 ➡️ 서버로의 데이터 전송) (0) | 2023.07.24 |
HTTP 웹 기본 지식(HTTP 메소드) (0) | 2023.06.08 |
HTTP 웹 기본 지식(인터넷 네트워크 정리/URI와 웹 브라우저 요청 흐름) (0) | 2023.06.08 |
Comments