방통대 기말고사가 끝났으니 미뤄둔 공부 목록을 해치워야겠다.
이번 학기에 정보통신망을 공부하면서 네트워크 공부를 같이했는데 http 통신 관련된 부분도 나와서 겸사겸사 복습겸 정리한다.
생각난 김에 정리하고 올려야 안 까먹을듯. 인프런의 김영한 강사님의 ‘모든 개발자를 위한 HTTP 웹 기초 지식’ 을 참고했으며 부족한 부분은 계속 채워나갈 예정이다.
- IP 프로토콜의 한계
- 비연결성 : 패킷을 받을 서버가 없거나 서비스 불능상태라도 패킷 전송
- 비신뢰성 : 패킷이 순서대로 전송되지않을 수있다. 전송 중 패킷이 소실될 수있다.
- 패킷 = package + bucket (전송할 데이터 덩어리)
- TCP
- 연결지향 - 일단 연결시키고 메세지를 보냄
- 데이터 전달 보증 - 데이터가 제대로전송이 되었는지 확인가능
- 순서보장 - 전송하는 패킷들의 순서를 보장해줌
- 최근엔 최적화가 되어서 3way handshake의 마지막 단계에서 데이터 함께 전송함
- 단, 3way handshake 는 논리적으로 연결된 것이다. 연결이 확인되었다고해서 중간의 수많은 서버들 사이의 연결이 보장된 것은 아님
- UDP
- IP와 거의 같다 .
- IP + PORT + 체크섬(메세지가 맞는지 검증)
- TCP는 3way handshaking, 큰 데이터 등으로 전송 속도가 느리다. 따라서 전송속도를 줄이기 위해 application level로 UDP를 사용해서 전송 최적화를 하는 추세다.
- PORT
- 한번에 여러 서버에 통신을 요청할때 사용
- 패킷에는 출발지 IP, PORT 도착지 IP, PORT , 전송데이터 + α 가 있다.
- IP가 아파트면 PORT는 동호수. 한 아파트(PC) 안에서 사람들(어플리케이션)가 사는 집을 구분해준다.
- DNS
- DNS서버에서 도메인명에 IP주소를 부여해 영문으로 주소를 써도 서버로 연결가능
- URI
- Uniform Resource Identifier
- 리소스를 식별하는 표준화된 방법
- URI 안에 URL, URN이 있음
- URL(Resource Locator) : 리소스가 있는 위치를 지정
- URN(Resource Name) : 리소스에 이름 부여
- URN의 이름만으로 리소스를 찾을 수 있는 방법은 보편화되어있지 않다.
- 보통 URI와 URL을 동일한 의미로 말함
- URL
- 프로토콜은 어떤 방식으로 자원에 접근할지 정하는 약속 규칙
- userinfo, host, port, path, query (query parameter, query string), fragment등이 들어간다.
- 웹 브라우저 요청 흐름
- URL 생성
- 웹 브라우저가 HTTP 메시지 생성
- SOCKET 라이브러리를 통해 웹브라우저에서 TCP/IP 계층으로 메시지 전달
- TCP/IP 패킷 생성( 출발지 IP,PORT + 목적지 IP, PORT + HTTP 메시지 )
- 웹 브라우저에서 서버로 요청 패킷 전송
- 서버에서 HTTP 응답 메시지 전송
- 웹 브라우저 HTML 렌더링
- HTTP
- 모든 것이 HTTP (Hyper Text Transfer Protocol)
- HTML, 이미지, 영상, 파일 모든 형태의 데이터 전송 가능
- TCP 직접 연결은 매우 드문 경우
- 1.1버전 현재 많이 사용하고 가장 중요하다. (RFC 7230~7235 버전)
- 2, 3 버전은 성능개선에 초점이 맞춰져있음
- HTTP /1.1, HTTP/2 → TCP 기반
- HTTP/3 → UDP 기반
- HTTP 버전확인 → 개발자 도구 → 네트워크 →마우스 오른쪽 → protocol (h2→ HTTP/2, h3→ HTTP/3)
- 클라이언트 - 서버 구조 : 클라이언트는 서버에 요청을 보내고 서버는 요청에 대한 결과를 클라이언트에게 보낸다. → 양쪽이 독립적으로 발전할수 있다 (중요)
- 무상태 프로토콜(stateless) : 서버가 클라이언트의 상태를 보존하지 않는다.
- stateful : 상태유지, 문맥 보존, 응답서버를 쉽게 바꿀 수 없음 같은 서버가 항상 유지되어야한다. 통신중 서버에 에러가나면 통신을 처음부터 다시해야함
- stateless : 상태를 유지하지 않음, 응답 서버를 쉽게 바꿀 수 있음, 클라이언트 요청이 증가해도 서버를 대거 투입가능(수평확장 scale-out)
- 한계: 상태유지가 필요한 경우가 있다. (ex 로그인 상태유지 → 브라우저 쿠키 + 서버 세션 ), 데이터를 너무 많이보낸다.
- 최대한 stateless로 설계하고 예외의 경우 stateful로 설계
- 비연결성 (connectionless) : 요청, 응답 후 연결을 끊음 → 최소한의 자원만을 사용할 수 있다, 여러 클라이언트의 요청을 받을 수 있다.
- 단점 : TCP/IP 연결을 새로 맺어야한다. - 연결 시간 소모
- HTTP 메시지를 통해 통신
- HTTP 요청 메세지 : 시작라인(HTTP method, path,HTTP 버전), 헤더(host), 공백라인,(메시지 바디)
- HTTP 응답 메세지 : 시작 라인(HTTP 버전, HTTP status), 헤더(content-type…), 공백라인(CRLF), 메세지 바디(html)
- 시작라인(start-line) : request-line, status-line
- 요청메시지request-line : method SP(SPACE) request-target SP(path) HTTP_version CRLF(엔터)
- HTTP method : GET(서버에 리소스 요청), POST(서버에 데이터 전송후 처리요청), PUT, DELETE
- 절대경로[?쿼리] : “/”로 시작하는 경로
- HTTP-version
- 응답메세지 status-line :
- HTTP 상태코드 : 200 성공 400 클라이언트 요청 오류 500 서버 내부 오류
- 요청메시지request-line : method SP(SPACE) request-target SP(path) HTTP_version CRLF(엔터)
- 헤더
- HTTP 전송에 필요한 모든 부가정보
- 메시지 바디의 내용, 크기, 압축여부, 브라우저 정보, 인증정보, 캐시관리 정보 등… 메시지 바디 제외 필요한 모든 메타정보가 다 들어있다.
- 임의의 헤더 추가시 약속된 클라이언트, 서버만 파악 가능
- 메시지 바디
- 실제 전송할 데이터가 들어있음 json, html, 이미지 등
Comments powered by Disqus.