HTTP정리 인프런 강의 (모든 개발자를 위한 HTTP 웹 기본 지식)

통신

HTTP정리 인프런 강의 (모든 개발자를 위한 HTTP 웹 기본 지식)

곰탁 2022. 3. 2. 21:40

[인터넷 네트워크]

인터넷 통신

- 클라이언트와 서버 사이에 인터넷이 있을때,

수 많은 중간 노드를 거쳐서 가게 됨.

- IP(인터넷 프로토콜)

주소 부여, 지정한 IP 주소에 데이터 전달

패킷이라는 통신 단위에 데이터 전달.

ip 패킷 정보

구성

출발지ip, 목적지ip, 기타 - 외부

전송 데이터 - 내부

IP 프로토콜의 한계

비연결성

패킷을 받을 대상이 없가나 서비스 불능인데 패킷이 전송이 됨.

비신뢰성

패킷이 사라지거나 여러개 보냈을때 순서대로 도착하지 않을 수 있다.

데이터가 크기에 따라서 패킷이 나눠서 전송되는데 그 패킷들이 하나의 노드를 이용한다는 보장이 없어 속도에 차이가 날 수 있음.

프로그램 구분

IP를 사용하는 서버에서 둘이상의 앱이 동작하고 있으면 구분해서 할 수 있나?

예 ) 게임을 하면서 스트리밍 음악을 들음.

위의 문제를 해결해 줄 수 있는게 TCP 통신

TCP,UDP

인터넷 프로토콜에 4계층

앱 계층 http ftp

전송계층 TCP UDP

인터넷 계층 IP

네트워크 인터페이스 계층

1. 프로그램이 메세지를 생성

2. 소켓 라이브러리를 통해 전달.

3. TCP 정보생성, 메세지 데이터 포함.

4. IP 패킷 생성, TCP 데이터 포함

이 후 랜카드에서 Ethernetframe을 통해서 물리적 주소 같은게 포장되어서 전달됨.

TCP 세그먼트는 출발지 포트, 목적지포트, 전송제어, 순서, 검증정보 등이 포함되어서 보내진다.

앞의 IP만으로 해결되지 않았던 단점들을 보완

TCP특징

전송 제어 프로토콜

연결지향 TCP 3 way handshake ( 먼저 연결 확인 후 데이터 전송함)

데이터 전달 보증 (중간에 패킷이 누락 될 경우 확인 가능)

순서 보장

신뢰할 수 있는 프로토콜

대부분 TCP 사용

TCP 3 way handshake

1. SYN: 접속요청

2. ACK: 요청 수락

3. ACK와 함께 데이터 전송 가능

개념적인 연결이지 물리적으로 연결 된 것이 아님.

서로 주고 받을 수 있는 상태를 연결로 보는 논리적 개념적 연결.

중간에 노드를 파악을 할 수 없음.

데이터를 전송 했을때 데이터를 잘 받았다고 답변이 옴.

순서보장

- 1,2,3을 전송했을때 1,3,2순으로 서버에 도착한다면, 서버는 스스로 순서를 정리하는게 아닌 클라이언트에게 패킷 2부터 다시보내라는 요청을 하게 됨.

(최적화를 서버가 하는 경우도 있긴 함)

UDP 사용자 데이터그램 프로토콜 User Datagram Protocol

기능이 없음.

하얀 도화지에 비유함.

IP프로토콜과 거의 같다. 포트 체크성 정도만 추가.

앱 추가 작업 필요.

TCP UDP 비교

TCP는 필요한 부가적인게 포함되어, 데이터 양도 크고 데이터 전송 속도가 느림. 커스터마이징 최적화를 할 수 없음.

PORT

한 클라이언트에 둘 이상 연결해야 할때 포트로 구분해여서 사용.

IP는 아파트 포트는 각 호수로 이해.

0~65535 할당가능

0~1023 잘 알려진 포트, 사용하지 않는 것이 좋음.

FTP - 20,21

TELNET - 23

(원격지의 호스트 컴퓨터에 접속할 때에 지원되는 인터넷 표준 프로토콜.)

(23번 포트를 통해서 원격 접속을 허용함.)

HTTP - 80

HTTPS - 443

DNS

도메인 네임 시스템

IP는 변동성이 있어서 사용이 어려움.

전화번호부 라는 개념

URI

URI? URL? URN?

Locator, Name 을 포함하는 개념 Identifier

URL 리소스가 여기 있을거야~

URN 리소스 이름은 이거

위치는 변할 수 있지만 이름은 변하지 않는다.

하지만 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음.

URL 전체문법

scheme://[userinfo@]host[:port][/path][?query][#fragment]

- scheme 주로 프로토콜 사용 http 80 https 443포트를 주로 사용, 포트는 생략 가능

- userinfo 거의 사용하지 않음.

- host 도메인명

- port 일반적으로 생략 가능

- path 리소스 경로 계층적 구조

- query key=value 형태로 들어감, ?로 시작 &로 추가함. 쿼리 파라미터, 쿼리 스트링으로 불림.

- fragment 잘 사용하진 않음. html 내무 북마크 등에 사용, 서버로 전송되는 정보는 아님.

HTTP Hyper Text Transfer Protocol

모든것이 HTTP

HTML, TEXT, IMAGE, JSON, XML 거의 모든 형태의 데이터 전송 가능.

서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

지금은 HTTP 시대!

HTTP/1.1
97년 가장 많이 사용

HTTP/2

15년 성능개선

HTTP/3 진행중
TCP 대신에 UDP 사용, 성능 개선

TCP : 1.1, 2

UDP : 3

HTTP 특징

클라이언트 서버 구조

- 요청 응답 구조

무상태 프로토콜

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

- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입하면 처리 가능.

- 스케일 아웃(수평 확장 유리)

- 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.

(예 : 로그인 / 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지)

- 상태 유지는 최소한만 사용

- 단점 : 데이터를 많이 보내야 한다.

비 연결성

- 최소한의 자원 사용

- HTTP는 기본이 연결을 유지하지 않는 모델

- 일반적으로 초 단위의 이하의 빠른 속도로 응답

- 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음.

- 서버 자원을 매우 효율적으로 사용할 수 있음.

(한계와 극복)

- TCP/IP 연결을 새로 맺어야 함.( 시간 추가)

- 웹 브라우저로 사이트를 요청하면 수 많은 자원이 함께 다운로드

- HTTP 지속 연결로 문제 해결

HTTP 지속 연결

- 기존에 연결 요청 응답 종료가 하나로 움직였다면, 여러가지 요청을 하나의 연결 종료 안에 실행한다.

HTTP 메세지

구조

시작라인

헤더

공백라인

메세지 바디

단순함, 확장 가능

시작라인

request-line / status-line

request-line = method SP(공백) request-tartget SP HTTP-version CRLF

응답 메세지

status-line = HTTP-version SP status-code SP reason-phrase CRLF

상태코드 :

200:성공

400:클라이언트 요청 오류

500:서버 내부 오류

이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

HTTP 헤더

header-field = field-name":"OWS(띄워도 되고 안띄워도 된다는 뜻) field-value OWS

용도

- HTTP 전송에 필요한 모든 부가 정보.

- 바디의 내용, 바디의 크기, 압축, 인증, 요청 정보, 캐시 관리 정보

- 메세지 바디 빼고 필요한 메타 정보 다 들어 있음.

메세지 바디

용도

- 실제 전송할 데이터

- 문서, 이미지, 영상, JSON, byte로 표현할 수 있는 모든 데이터 전송 가능

HTTP API를 만들어보자

가장 중요한 것은 리소스 식별

리소스와 해당 리소스를 대상으로 하는 행위를 분리

리소스는 명사, 행위는 동사

URI 설계 / 리소스 식별, URL 계층 구조 활용

HTTP 메서드 - GET, POST

GET: 리소스 조회

POST: 요청 데이터 처리, 주로 등록에 사용

PUT: 리소스를 대체, 해당 리소스가 없으면 생성

PATCH: 리소스 부분 변경

DELETE: 리소스 삭제

기타 메서드

HEAD: GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환

OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명(주로 CORS에서 사용)

CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE: 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행

POST

POST는 서버로 요청을 보낼때 데이터를 처리해달라고 하는 점이 GET과의 차별점.

1. 새 리소스 생성

2. 요청 데이터 처리

- 프로세스를 처리해야하는 경우.

3. 다른 메서드로 처리하기 애매한 경우

HTML Form 데이터 전송.

method 가 get이면 URL에 POST면 body에 파라미터가 나감.

urlencoded가 기본. 한글 같은건 변형됨.

multipart/form-data : byte로 되어 있는 파일도 같이 넘길때.

Content-Type : multipart/form-data; boundary = ---XXX

(---XXX 이걸로 파일을 구분해서 잘라줌. 바이너리 데이터들을 전송할 때 사용됨. )

다른 종류의 여러 파일과 폼의 내용 함께 전 가능( 그래서 이름이 multipart)

HTML Form 전송은 GET, POST만 지원!

HTTP API 데이터 전송

서버 to 서버

앱 클라이언트

웹 클라이언트

HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)

POST,PUT,PATCH: 메세지 바디를 통한 데이터 전송

GET: 조회, 쿼리 파라미터로 데이터 전달.

Content-Type: application/json을 주로 사용(사실상 표준)

- TEXT,XML,JSON 등등

예)

회원 목록 조회 /members

회원 조회 /members/

회원 등록 /members/

회원 수정 /members/

회원 삭제 /members/

아아아아아아아아 중간에 날려버렸네 다시 안적음...

스토어.. 컬렉션 컨트롤 URI 중요한 개념이지만.. put post 기반 차이점.

정리하면 좋은 URI 설계 개념

문서(document)

단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)

예)/members/100, /files/start.jpg

컬렉션(collection)

서버가 관리하는 리소스 디렉터리

서버가 리소스의 URI를 생성하고 관리

예) /members 에 담아서 POST담으면 서버에서 /members/100으로 리턴

스토어(store)

클라이언트가 관리하는 자원 저장소

클라이언트가 리소스의 URI를 알고 관리

예) /files /files/{filename} PUT

컨트롤러(controller), 컨트롤러 URI

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행

동사를 직접 사용

예) /members/{id}/delete

https://restfulapi.net/resource-nameing