HTTP 내용 필기

인프런 김영한 강사님의 [모든 개발자를 위한 HTTP 웹 기본지식] 강의 필기입니다.

내용참고 목적으로만 활용해주시면 감사하겠습니다.

---

chap.1 인터넷 네트워크

@IP 프로토콜

패킷 전송의 신뢰성이 확보되지 못함

 

@TCP 프로토콜

ip 프로토콜을 개선하기 위해 등장

전송제어 --> 패킷 전송의 신뢰성 확보

 

#패킷을 전송시 아래 계층으로 내려오면서 내용이 추가됨

예를 들어 채팅메시지A를 전송시

TCP에서 정보B가 추가됨

IP에서 정보C가 추가됨

LAN 정보D가 추가됨

최종 A+B+C+D 정보가 전송된다

 

@TCP 와 UDP

#TCP

.TCP 안에 들어있는정보

--> (IP와 공통) 출발지와 도착지의 url

(추가) 출발지와 도착지의 port, 전송제어, 순서, 검증 정보

.내용의 신뢰성 확보됨

.3 way handshake

클라이언트 ; syn

서버 ; syn + ack

클라이언트 ; ack

.데이터 전달 보장

데이터를 수신하면 수신했다고 응답을 한다

.데이터 순서 보장

패킷 순서가 잘못되면 이상한 순서에서부터 다시 전송하라고 요청하게 됨

.이것저것 데이터가 많아서 데이터 양도 많고 무겁다

 

#UDP

.기능이 없다...?

.IP와 거의 동일하다

.대신 port정보와 체크섬 정보만 추가된다(이건 tcp와 동일함)

.빠르고 가벼운 데이터 전송에 활용

 

#웹 개발에서 적용하는 통신

tcp --> 데이터 양이 크고 전송속도를 빠르게 만들기 어렵다

더이상 손대기 어렵다

udp --> 최적화를 위한 개발대상

여기에 손을 댄다

개발자가 원하는 최적화의 대상

(즉 백지와 같아서 이것저것 작업할 수 있음)

원래 TCP가 시장의 90퍼센트 점령함

실시간 전송이 필요한 동영상 등도 tcp를 활용했음

근데 최근 UDP를 활용하는 방향으로 변동되기도 하니 지켜볼 것

 

#PORT

특정 ip주소 안에 있는 애플리케이션을 찾을 때 사용하는 경로

클라이언트에서 서버에 패킷을 보낼 때

출발지와 목적지의 ip, port 정보를 보낸다

덕분에 서버에서도 다시 데이터를 전송할 때 어디로 보낼지 확인하고 전송할 수 있다

 

ip ; 아파트

port ; 호수

 

#DNS

.일종의 전화번호부

dns 서버에 도메인명과 IP주소를 갖고 있다

클라이언트에서 도메인명으로 ip주소를 요청하면 ip주소를 반환해준다.

클라이언트는 반환받은 ip주소로 서버에 접근해 페이지 정보를 요청한다

---

chap.2 URI와 웹 브라우저 요청 흐름

 

#URI - uniform resource identifier

자원을 식별하는 식별자(다른 항목과 구분하기 위한 유일한 정보)

locator; 위치를 알려줌

name ; 그 자체를 가리킴

uri 안에 url과 urn 이 포함된다

 

#URL

uniform resource locator

리소스가 있는 위치를 지정

 

#URN

uniform resource name

리소스 자체에 이름을 부여

위치는 변경될 수 있지만 이름은 변경되지 않는다

인터넷 환경에서 urn으로 리소스를 찾기는 보편화되지 않음

그래서 uri 와 url은 사실상 같은 의미이다

보통 URL 을 사용한다. URI 에는 URL 과 URN 이 포함된다

 

 

#브라우저가 데이터를 주고받는 과정

브라우저가 DNS 시스템을 통해 도착지의 ip, port 정보를 확인한다

HTTP 요청 메시지를 생성한다

쿼리정보/호스트정보/버전정보 등등 추가해서 생성한다

 

 

#http 메시지 전송하는 절차

메시지는 하위계층을 단계적으로 통과하면서 정보가 추가된다

마지막 네트워크 계층에서 인터넷을 통해 메시지를 전송하게 된다.

 

1. 애플리케이션 계층

웹 브라우저; HTTP 메시지 생성

Socket library 통하게 된다

2. OS 계층- TCP/IP

3 way handshake 를 하면서 클라이언트-서버 연결 보장

연결이 되었으면 http 메시지에 ip/port 정보를 더한다

(메시지의 겉에 ip/port 정보로 감싼다)

3. 네트워크 인터페이스 계층

Lan 드라이버/장비 등을 거치며 정보 추가

패킷 전송

#http 메시지 수신

1. 패킷을 수신한다

2. 내부에 위치한 http 메시지 정보를 취한다

3. 요청정보를 해석한다

4. 요청에 해당하는 데이터를 찾는다

5. 응답 메시지를 구성한다

응답번호/ content-type(유형... http 등 )/content-length(http실제길이)

---

chap.3 HTTP 기본

HTTP 란

.HyperText Transfer Protocol

.거의 모든 형태의 데이터 전송 가능

.서버간 데이터 전송시 주로 사용하는 방식

.실무에서 TCP를 직접 연결하는 경우는 거의 없다. http를 통하게 됨. 특수한 경우를 제외하고는 http를 사용함

 

@http역사

http1.1

.대부분의 기능이 탑재됨

.그 뒤로는 성능개선이 이루어짐

.현재 주로 사용하는 버전

@http 특징

1) 클라이언트와 서버구조

요청과 응답구조

request - response

클라이언트와 서버를 분리하였다

서버는 비즈니스 로직, 데이터 집중

클라이언트는 UI, 사용성에 집중

2) 무상태 프로토콜

>> stateful ; 상태유지

.쉽지 않은 방식

.클라이언트가 같은 서버와 통신해야하기 때문

.서버가 만약 끊긴다면 처음부터 단계를 밟아나가야 함

>> stateless ; 상태유지 x / 무상태

현재 사용하는 방식이다

.http 는 상태를 유지하지 않는다

.무상태 -> 클라이언트가 서버에 필요한 정보를 모두 넘긴다

.중간에 점원이 바뀌더라도 문제 없음

.클라이언트가 증가되더라도 서버를 유연하게 증가시킬 수 있음

.무상태는 응답 서버를 쉽게 바꿀 수 있다. 덕분에 무한한 서버 증설이 가능하다

.수평적으로 확장 가능성이 열려있음

.서버는 상태를 보관하지 않고 클라이언트가 모든 정보를 넘겨준다

.다른 서버에서 응답을 해줄 수 있음

>> stateless 의 실무한계

.로그인이 필요없는 정적인 페이지에 적합

.로그인 등 상태를 유지해야하는 경우에는 적합하지 않다

.무상태를 사용할 수 있으면 최대한 무상태로 구성하고, 상태유지는 최소한만 사용하게 됨

.클라이언트가 서버에 데이터를 너무 많이 보낸다

3) 비연결성

.필요할 때만 연결하고 응답이 끝나면 즉시 연결이 종료됨

.자원을 아끼고 호율적으로 사용할 수 있음

.대신 연결할 때 tcp/ip 연결을 새로 맺어야함(3way handshake 작업)

.이 과정을 할 때마다 수많은 자원이 함께 매번 다운로드 됨

 

---

chap.4 HTTP 메서드 기본

@http api 설계해보기

.uri는 리소스만 식별하도록 하기

.복수형 단어 사용이 권장된다(컬렉션으로 취급)

.리소스와 행위 분리하기

@주요 메서드

.get; 리소스 달라고 요청. 리소스 조회

.post ; 요청데이터에 따른 처리

.put ; 리소스 대체. 없으면 새로 생성

마치 파일 덮어쓰기와 같다

.patch ; 리소스 특정부분 변경하기

.delete ; 리소스 삭제

.head ; 메시지 바디를 제외한 헤더만 요청

.options ;

.connect ; 거의 사용 안함

 

#get 메서드

.리소스 조회용

.전달이 필요한 데이터는 query(query parameter, query String)등을 통해 전달함

#post 메서드

요청데이터에 따른 데이터 처리 요청

메시지 바디에 데이터를 전달함

.의미: 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청

 

post 를 사용하는 경우 

.리소스를 새로 생성하거나 신규등록 하는 경우

.요청 데이터를 처리하는 경우

단순히 생성 및 변경이 아닌 프로세스를 처리하는 경우

혹은 프로세스의 상태가 변화되는 경우

.다른 메서드를 사용해 처리하기 어려운 경우

#put 메서드

.리소스가 있으면 대체, 없으면 생성

.리소스를 완전히 대체한다

.덮어쓰기

.(post와의 차이점) 클라이언트가 리소스의 위치를 알고 uri를 지정한다

.클라이언트가 리소스 위치를 정확히 알고 접근 및 리소스를 대체[생성]한다는 의미

.리소스를 완전히 대체

-> 기존 리소스가 완전히 사라진다... -> 기존 내용 복구 불가능

-> 리소스를 수정하는게 아니라 갈아치우는 것이다

 

#patch

.리소스의 특정 부분만 변경하는 경우 사용하는 방식(전체수줭이 아닌 부분수정의 경우 적용)

.http가 patch 를 지원하지 않는경우 post를 사용하면 됨

왜냐하면 post는 모두 지원하기 때문이다

@http 메서드의 속성

-안전 / 멱등 / 캐시가능 등으로 속성을 확인할 수 있음

 

.안전

-여러번 호춭했을 때에도 대상 리소스가 변경이 발생하지 않는것

-호출시 변경 여부

get, head : 안전하다

post, patch, delete 등 : 안전하지 않다(변경이 일어나기 때문에)

.멱등 Idempotent

-1번 호출과 n번 호출결과가 동일함

.1번이든 여러번 하든 최종 결과가 동일한가

get : 멱등

put : 멱등

delete : 멱등

post : 장애가 발생할 수 있다. 서비스 오류 발생

.캐시 가능 cashable

-캐시 ; 로컬pc가 데이터나 값을 복사해둠

-get, head 방식이 캐시로 사용됨

-응답결과 리소스를 웹브라우저가 캐시해도 되는지

---

chap.5 HTTP 메서드 활용

 

클라이언트에서 서버로 데이터 전송하기

1. 데이터 전송방식

1) 쿼리 파라미터를 통한 전송

.방식: get

.특정 단어로 검색을 하거나

게시판 정렬 조건을 넣는 경우에 활용됨

2) 메시지 바디를 통한 전송

.방식: post, put, patch

 

2. 상황별 데이터 전송

1) 정적 데이터 조회

.get 방식

.쿼리파라미터 없이 서버에 있는 리소스 경로를 클라이언트에 제공해 조회가능하도록 함

.주로 정적인 문서를 조회하는 경우에 사용

2) 동적 데이터 조회

.get 방식

.전달된 쿼리파라미터를 통해 보여줄 데이터를 sort 및 정렬해 가져온다

.주로 게시판 조회 및 검색하는 경우에 사용

 

3) HTML form 으로 데이터 전송

--> get / post  두가지방식만 허용된다

# method= POST

.메시지 바디

.폼-submit 버튼을 클릭하면 브라우저에서 http 메시지를 생성함

.key-value를 쿼리 파라미터와 동일한 방식으로 전송하게 됨

# method= GET

.메시지 바디

.get 방식은 메시지 바디를 사용하지 않는다

.즉 쿼리 파라미터에 값을 할당해 서버에 값을 전달함

.리소스 변경이 이루어지는 요청에 사용해서는 안되는 방식이다. 단순 조회기능에만 사용할 것

# enctype = multipart/form-data

.바이트 코드로 이루어진 데이터도 전송하기 위한 방식

. multipart/form-data 를 적용하면 바이트 코드 파일, 즉 이미지, 음원파일, 동영상 등도 전송할 수 있다

.파일 업로드시에는 바이트 코드로된 파일까지 전송해야 하기 때문에 다른 전송방식이 필요함

.예를 들어 이미지를 업로드 하면 이미지에 대한 바이트정보도 전송해야하기 때문이다

4) http api를 통한 데이터 전송

.html 폼을 사용하지 않는 거의 모든 전송방식

.서버끼리 통신할 때 / 앱 클라이언트(아이폰, 안드로이드)에서 전송할 때 / 웹 클라이언트에서 ajax 통신시

.content-type: application/json을 주로 사용함

.요즘에는 xml을 별로 사용하지 않는다. json이 표준임

.REST API 와 HTTP API는 엄밀히 말하면 다르지만 사실상 같은 의미로 사용된다

.http api는 http를 사용해 서로 정해둔 스펙으로 데이터를 주고 받으며 통신하는 것이다

.REST ful API ; Representational State Transfer

http 프로토콜 장점을 최대 활용할 수 있는 네트워크 기반 아키텍처

http 메서드를 사용해 서버와 통신하는 것을 말한다

 

 

@HTTP API 설계 예시

1. http api

 

1) POST 방식 -> collection

ex. 회원관리시스템

. 설계

회원 목록 /members -> GET

회원 등록 /members -> POST

회원 조회 /members/{id} -> GET

회원 수정 /members/{id} -> PATCH(변경하기), PUT(덮어쓰기), POST

회원수정의 경우 put 보다는 patch 를 추천한다.

모든내용을 전송하지 않으면, 포함되지 않은 내용은 그냥 날아감

대신 게시글수정의 경우 put 이 적절할 수 있다. 부분 수정이 아닌 처음부터 완전 수정이니까

잘 모르면 그냥 천하무적 post 를 사용하면 된다

회원 삭제 /members/{id} -> DELETE

 

.절차

클라이언트에서 post 방식으로 데이터를 전달함

클라이언트는 등록될 리소스의 uri를 모른다

서버에서 데이터를 전달받아 새로운 리소스와 URI를 생성한다

(클라이언트는 데이터를 전송하기만 할 뿐이다)

그리고 uri 정보를 클라이언트에 반환한다

.서버가 관리하는 방식을 컬렉션 collection 라고 한다

리소스를  생성하고 관리하는 주체 : 서버

 

 

2) PUT 방식 -> store

ex. 파일관리시스템

원격지에서 파일관리(FTP 같은 ?)

 

. 설계

파일 목록 /files -> GET

파일 조회 /files/{filename} -> GET

파일 등록 /files/{filename} -> PUT

파일 삭제 /files/{filename} -> DELETE

파일 대량 등록 /files -> POST

 

.절차

파일을 등록하는 경우 put 이 적절하다

-> 덮어쓰기(기존 파일 지우고 다시 올리기에 적합)

.파일 신규등록하는 경우

.클라이언트가 리소스의 uri를 알고 직접 지정해준다

.=클라이언트가 파일의 주소를 알고 있으며 관리의 책임도 있음

.서버는 요청대로 해주기만함

.클라이언트가 관리하는 방식을 컬렉션 store 라고 한다

리소스를  생성하고 관리하는 주체 : 클라이언트

 

*put 보다는 post 기반, 즉 컬렉션 방식의 시스템을 많이 사용함

 

2. html FORM 사용

.설계

회원 목록 /members -> GET

회원 등록 폼 /members/new -> GET

(폼 자체를 보는 것은 변경이 이루어지지 않기 때문에 get을 사용할 수 있음)

회원 등록 /members/new, /members -> POST (두가지 방법으로 설계 가능)

회원 조회 /members/{id} -> GET

회원 수정 폼 /members/{id}/edit -> GET

회원 수정 /members/{id}/edit, /members/{id} -> POST (두가지 방법으로 설계 가능)

회원 삭제 /members/{id}/delete -> POST

 

.특징

회원관리 -> 등록, 수정, 삭제 등시에는 post 방식 사용

get/ post 만 지원해서 제약이 있음

 

.컨트롤 URI

동사로 된 리소스 경로를 사용해 제약을 해결함

ex. new/ edit / delete 등

 

 

---

chap.6 HTTP 상태코드

1xx. Informational

요청이 수신되어 처리중

거의 사용되지 않는 코드

 

2xx. Successful

200 ok ; 요청 정상 응답

201 created ; post등으로 리소스 생성

202 accepted

요청을 접수했으나 처리되지 않음

batch 처리 같은 곳에서 사용된다

접수한 시점과 처리시점이 다를때

잘 사용안되는 코드

204 no content

서버가 요청을 성공적으로 수행. 응답 페이로드 본문에 보낼 데이터가 없음

문서 편집기에서 저장 버튼을 클릭하면 서버는 저장한다.

대신 클라이언트는 문서를 그대로 편집 가능하다

3xx. redirection

.요청이 완료되려면 클라이언트의 추가적인 활동이 필요한 경우

.user agent : 클라이언트 프로그램 -> 즉, web browser

.웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(=리다이렉트)

#과정

서버에서 3xx 응답을 한다

응답에는 Location 코드가 포함된다

클라이언트의 웹 브라우저는 전달받은 새로운 Location 요청정보로 다시 요청한다

서버는 다시 응답한다

#리다이렉트 종류

1) 영구적인 리다이렉션

.코드 ; 301, 308 -> 역할이 같다

.uri 가 영구적으로 이동함

301 코드 ; post 오면 다시 get으로 전환해 신규 주소로 전달

301 코드 ; post 오면 post 유지하면서 신규 주소로 전달

308보다는 301을 좀더 사용한다

2) 일시적인 리다이렉션

.코드; 302, 307, 303 -> 주요 기능은 같다

3) 특수 리다이렉션

---

chap.7 일반 헤더