2023.05.22 Spring
김영한 스프링 HTTP
모든 개발자를 위한 HTTP 웹 기본 지식
1. 강의소개
앱과 서버 서버와 서버가 통신할때 HTTP를 사용한다.
모두 HTTP를 기반으로 이루어져있다.
수많은 기능과 용어가 있는데 명확하게 이해하기가 어렵다.
단순히 기능과 사용방법만 알게 된다.
강의 목표
개발자는 평생 HTTP기반위에서 개발한다.
언젠가 한번은 HTTP 정리해야한다.
HTTP 전체흐름이해 실무에 꼭 필요한 핵심내용
API어떻게 설계할지 등등을 배울수 있다.
인터넷네트워크 프로토콜 계층 TCP DNS
URI 요청흐름
웹브라우저에서 엔터쳣을때 하부구조 어떻게 작동하는지
HTTP기본 특징 무상태 지속연결 구조
HTTP메소드 무작정 API URI설계 HTTP 메소드 속성
활용방법 쿼리 FORM API API설계예시
HTTP상태코드 200 300 400 500
HTTP헤더 너무많아서 묶음으로 등등
HTTP캐시 필요한 이유
sec2 인터넷 네트워크
HTTP인데 왜 인터넷이 중요한가? 인터넷을 기반으로 하기 때문이다.
2. 인터넷 통신
인터넷상에서 컴퓨터 둘은 어떻게 통신하나
인터넷망을 통해서 보내야한다. 수많은 중간 노드를 거쳐서 넘어가게 된다.
어떻게 이것을 돌아서 가나? IP의 개념에 대해서 알아야한다.
3. IP(인터넷 프로토콜)
복잡한 인터넷명에서 최소한의 규칙이 잇어야하는데 이것이 IP주소이다.
IP인터넷 프로토콜 역할
지정한 IP주소(IP Address)에 데이터를 전달한다.
패킷(Packet)이라는 통신 단위로 데이터를 전달한다.
IP패킷이라는 규칙이있다. 출발지 목적지 기타를 담아서 간다.
서버들이 규약을 따르고 잇어서 서로 노드끼리 던지고 최종적으로 목적지에 도달하게 된다.
참고로 요청시와 응답시에 루트가 다를 수 있다.
IP 프로토콜의 한계가 세가지가 있다.
1.비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송된다.
2.비신뢰성
중간에 패킷이 사라지면? 패킷이 순서대로 안오면?
3.프로그램 구분
같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?
한PC에서 게임 음악 듣고 있을때 프로그램을 어떻게 판별하나
이런 한계점이 발생하면 클라이언트는 문제가 발생했는지 알 수 없다.
4. TCP, UDP
IP의 한계점과 관련한 해결해주는 것이 TCP와 UDP이다.
인터넷 프로토콜 스택의 4계층
애플리케이션 계층 - HTTP, FTP
전송 계층 - TCP, UDP
인터넷 계층 - IP
네트워크 인터페이스 계층(랜카드 랜드라이버 등등)
IP위에 TCP같은 것을 올려서 보완해주는 것이다.
프로토콜 계층은 다음과 같은 단계를 가진다.
1.프로그램이 Hello, world! 메시지 생성
2.SOCKET 라이브러리를 통해 전달
3.TCP 정보 생성, 메시지 데이터 포함
4.IP 패킷 생성, TCP 데이터 포함
TCP/IP통신을 할때 다음과 같이 패킷을 구성하게 된다.
IP 패킷
출발지 IP, 목적지 IP, 기타...
TCP정보
출발지 PORT, 목적지 PORT
전송 제어, 순서, 검증 정보...
전송 데이터
TCP 특징
전송 제어 프로토콜(Transmission Control Protocol)
연결지향 - TCP 3 way handshake (가상 연결)
연결이 되었는지 안됬는지 확인한다.
데이터 전달 보증 누락되면 알 수 있다.
순서 보장
신뢰할 수 있는 프로토콜이라서 현재는 대부분 TCP 사용한다.
TCP 3 way handshake은 다음과 같다.
클라이언트에서 서버로 SYN이라는 메세지를 보낸다
그리고 서버에서는 SYN과 요청수락한다는 ACK메시지를 보낸다.
클라이언트는 다시 요청수락한다는 ACK메시지를 보내게 된다.
이 과정을 거치고 데이터를 전송하게 된다.
이것은 진짜로 연결된 것이 아니라 개념적으로 연결된 것이다.
논리적으로 연결되었고 중간에 수많은 노드들을 거치는 것은 상관 안쓰게 된다.
전용 랜선이 생긴건 아니다.
클라이언트에서 데이터를 보내면 데이터를 받았다는 응답을 하기 때문에 데이터전달보증이된다.
UDP 특징
UDP는 TCP와 같은 계층에 있다.
사용자 데이터그램 프로토콜(User Datagram Protocol)
하얀 도화지에 비유된다. 기능이 거의 없다.
연결지향 - TCP 3 way handshake X 데이터 전달 보증 X 순서 보장 X
데이터 전달 및 순서가 보장되지 않지만 단순하고 빠르다.
최근에 각광을 받고 있다. 시간이 지나며 TCP가 정립되었는데 웹브라우저에서 더 최적화를 하게 되었다.
그러면서 UDP를 쓰려고하는 것도 생긴다.
정리
IP와 거의 같다. 그런데 포트와 체크섬 정도만 추가되었다.
애플리케이션에서 추가 작업 필요하다.
5. PORT
배가 도착하는 항구라는 뜻이다.
한번에 게임, 화상통화 등등 을 여러개 둘 이상을 연결해야할때 구분을 해줘야한다.
클라이언트가 여러개와 통신해야한다.
어디의 패킷인지 알 수 없다.
TCP패킷안에 PORT번호가 있다.
IP는 목적지를 찾는거고 PORT는 안에서 프로그램을 찾게 된다.
같은 IP내에서 프로세스를 구분하는게 PORT이다.
PORT
0 ~ 65535 할당 가능하다.
0 ~ 1023: 잘 알려진 포트 사용하지 않는 것이 좋다.
FTP - 20, 21
TELNET - 23
HTTP - 80
HTTPS - 443 (HTTP에 보안이 추가된것이다.)
6. DNS
간단하게 알아보자.
IP는 기억하기 어렵다. 또한 변경될 수도 있다.
DNS
도메인 네임 시스템(Domain Name System)
전화번호부라고 할 수 있다.
도메인 명을 IP 주소로 변환한다.
DNS서버에 도메인명을 등록할 수 있다.
먼저 도메인으로 찾으면 DNS서버가 IP를 제공하게 된다.
URI와 웹 브라우저 요청 흐름
7. URI
URI(Uniform Resource Identifier)
URI? URL? URN?
URI는 로케이터(locator), 이름(name) 또는 둘다 추가로 분류될 수 있다
URI라는 큰 범주안에 URL과 URN이 있는 것이다.
각 리소스의 위치, 리소스의 이름을 의미한다.
URN은 이름을 부여해버리는 것이다. 찾기힘들어서 거의 URL만쓴다.
URI
단어 뜻
Uniform: 리소스 식별하는 통일된 방식
Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)
웹브라우저 실시간교통정보, 웹사이트 파일 등 식별할 수 있으면 다 리소스이다.
Identifier: 다른 항목과 구분하는데 필요한 정보
URL: Uniform Resource Locator 리소스가 있는 위치를 지정
URN: Uniform Resource Name 리소스에 이름을 부여
위치는 변할 수 있지만, 이름은 변하지 않는다.
urn:isbn:8960777331 (어떤 책의 isbn URN)
URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않다.
URL
전체 문법
scheme://[userinfo@]host[:port][/path][?query][#fragment]
https://www.google.com:443/search?q=hello&hl=ko
프로토콜(https)
호스트명(www.google.com)
포트 번호(443)
패스(/search)
쿼리 파라미터(q=hello&hl=ko)
7.1 scheme
scheme://[userinfo@]host[:port][/path][?query][#fragment]
https://www.google.com:443/search?q=hello&hl=ko
주로 프로토콜 사용
프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙이다.
예) http, https, ftp 등등이 있다.
http는 80 포트, https는 443 포트를 주로 사용 포트는 생략 가능하다
https(HTTP Secure)는 http에 보안 추가한것이다. 대부분의 사이트가 변경하고 있다.
7.2 userinfo
URL에 사용자정보를 포함해서 인증할때 작성한다.
거의 사용하지 않는다.
7.3 host
호스트명
도메인명 또는 IP 주소를 직접 사용가능하다.
7.4 PORT
포트(PORT)
접속 포트
일반적으로 생략한다. 생략시 http는 80, https는 443이다.
특정서버에 따로 접근해야하면 필요하다.
7.5 path
리소스 경로(path), 계층적 구조이다.
예)
/home/file1.jpg
/members
/members/100, /items/iphone12
7.6 query
key=value 형태
?로 시작, &로 추가 가능하다 ?keyA=valueA&keyB=valueB
query parameter, query string 등으로 부른다.
웹서버에 제공하는 파라미터, 문자 형태이기때문이다.
7.7 fragment
fragment
html 내부 북마크 등에 사용한다
서버에 전송하는 정보는 아니다.
8. 웹 브라우저 요청 흐름
URI를 보내면 DNS서버를 조회해서 IP를 얻어온다. 포트는 생략해서 본다.
HTTP요청 메세지를 생성한다.
요청하면 다음과 비슷한 요청을 만들어낸다.
GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com
1.웹 브라우저가 HTTP 메시지 생성
2.SOCKET 라이브러리를 통해 전달
-A: TCP/IP 연결(IP, PORT)
-B: 데이터 전달
3.TCP/IP 패킷 생성, HTTP 메시지 포함
이 패킷 정보가 인터넷으로 흘러가게 된다.
수많은 노드를 통해서 도착지에 가서 해석을 하게 된다.
다시 서버에서 HTTP 응답메시지를 작성해서 다시 클라이언트에게 전달하게 된다.
HTTP 기본
9. 모든 것이 HTTP
HTTP는 HyperText Transfer Protocol의 약자이다.
문서간의 html을 전송하는 프로토콜이었다.
현재는 모든 것이 HTTP이다.
HTTP 메시지에 모든 것을 전송한다.
HTML, TEXT
IMAGE, 음성, 영상, 파일
JSON, XML (API)
거의 모든 형태의 데이터 전송 가능하다.
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용한다.
tcp직접 연결해서 하는 경우는 거의 없다.
모바일도 http열어서 통신하는 등의 일을 한다.
HTTP 역사
HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
HTTP/1.0 1996년: 메서드, 헤더 추가
HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
HTTP/2 2015년: 성능 개선
HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선
2나 3이 중요한가? 아니다. 1.1에 거의 모든게 있고 성능개선된 버전이다.
기반 프로토콜
TCP: HTTP/1.1, HTTP/2
UDP: HTTP/3
현재 HTTP/1.1 주로 사용하고있고 HTTP/2, HTTP/3 도 점점 증가하고 있다.
어떻게 통신되고 있는지를 보고싶으면 브라우저에서 개발자 도구를 키면된다.
HTTP 특징
클라이언트 서버 구조이다.
무상태 프로토콜(스테이스리스)을 지향한다. 비연결성이다.
HTTP 메시지를 통해서 소통한다.
단순하고 확장 가능하다.
10. 클라이언트 서버 구조
클라이언트 서버 구조
Request Response 구조
클라이언트는 서버에 요청을 보내고, 응답을 대기한다.
서버가 요청에 대한 결과를 만들어서 응답한다.
이렇게 분리하는게 중요하다 옛날에는 한 뭉텡이로 있엇다.
비즈니스 로직이나 데이터를 서버한테 몰아넣고
클라이언트는 ui 사용성 그런데에 집중한다.
그러면 독립적으로 각각 진화할 수 있다.
11. Stateful, Stateless
HTTP는 무상태 프로토콜을 지향한다.
스테이스리스(Stateless)
서버가 클라이언트의 상태를 보존하지 않는다.
장점: 서버 확장성 높음(스케일 아웃)
단점: 클라이언트가 추가 데이터 전송
Stateful, Stateless 차이
정리
상태 유지: 중간에 다른 점원으로 바뀌면 안된다.
중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.
무상태: 중간에 다른 점원으로 바뀌어도 된다.
갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능하다.
상태 유지 - Stateful
항상 같은 서버가 유지되어야 한다. 중간에 서버가 장애나면 요청을 잃어버리게 된다.
Stateless
실무 한계
모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
또한 데이터를 너무 많이 보낸다.
무상태
예) 로그인이 필요 없는 단순한 서비스 소개 화면
상태 유지
예) 로그인
로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
상태 유지는 최소한만 사용해야한다.
12. 비연결성
TCP IP는 요청과 응답을 하면서 연결을 계속 유지하고 잇어서 서버 자원이 소모된다.
이것의 단점은 클라이언트가 놀고 있어도 유지해야한다는 단점이 있다.
비연결성은 자원을 주고받을때만 연결하고 최소한의 자원만 사용한다.
비 연결성
HTTP는 기본이 연결을 유지하지 않는 모델
일반적으로 초 단위의 이하의 빠른 속도로 응답한다.
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
비연결성을 이용하면 서버 자원을 매우 효율적으로 사용할 수 있다.
한계와 극복
TCP/IP 연결을 새로 맺어야 한다. 3 way handshake 시간 추가된다.
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드된다.
지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결한다.
HTTP/2, HTTP/3에서 더 많은 최적화되어있다.
스테이스리스를 기억하자
서버 개발자들이 어려워하는 업무
정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
예) 저녁 6:00 선착순 1000명 치킨 할인 이벤트
-> 수만명 동시 요청 이러면 비연결성이 소용이 없다.
최대한 비연결성으로 짜는 것이 중요하다.
보통 놀게하고 참여하거나 보다가 누르거나 그런것을 하게 만든다.
13. HTTP 메시지
시작라인 헤더 공백 MESSAGE BODY로 이루어져 있다.
HTTP 요청 메시지
요청방법 패스 http버전
헤더
요청 메시지도 body 본문을 가질 수 있다.
HTTP 응답 메시지
시작라인이 다르다
HTTP버전 요청한 처리 내역
헤더
공백
응답메시지
HTTP-message = start-line
( header-field CRLF )
CRLF
[ message-body ]
13.1 시작 라인
request-line과 status-line으로 이루어져있다.
요청메시지
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
HTTP 메서드 (GET: 조회)
요청 대상 request-target (/search?q=hello&hl=ko)
HTTP Version
13.1.1 요청 메시지 - HTTP 메서드
종류: GET, POST, PUT, DELETE 등
서버가 수행해야 할 동작 지정
GET: 리소스 조회
POST: 요청 내역 처리
13.1.2 요청 메시지 - 요청 대상
absolute-path[?query] (절대경로[?쿼리])
절대경로= "/" 로 시작하는 경로
참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다
13.1.3 - HTTP 버전
HTTP Version이 적혀있다.
13.2 응답 메시지
request-line과 status-line으로 이루어져있다.
status-line = HTTP-version SP status-code SP reason-phrase CRLF
HTTP 버전
HTTP 상태 코드: 요청 성공, 실패를 나타냄
200: 성공
400: 클라이언트 요청 오류
500: 서버 내부 오류
이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글(ok, error등등)
13.3 HTTP 헤더
header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name은 대소문자 구문 없다.
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.comHTTP 헤더
용도
HTTP 전송에 필요한 모든 부가정보이다.
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보,
서버 애플리케이션 정보, 캐시 관리 정보...
표준 헤더가 너무 많다.
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
필요시 임의의 헤더 추가 가능
helloworld: hihi
13.4 HTTP 메시지 바디
용도
실제 전송할 데이터이다.
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능하다.
HTTP는 단순하고 확장 가능하다.
HTTP는 단순하다.
HTTP 메시지도 매우 단순하다.
HTTP 정리
HTTP 메시지에 모든 것을 전송
HTTP 역사 HTTP/1.1을 기준으로 학습
클라이언트 서버 구조
무상태 프로토콜(스테이스리스)
HTTP 메시지
단순하고 확장 가능하다.
2023.05.22
HTTP의 개념과 의미 HTPP의 의미는 어렴풋이 알지만 그 직접적인 내용에 대해 생각해본적이 없다.
이번기회를 통해 HTTP의 의미에 대해서 알아보고자 한다.