HTTP 헤더

  • header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
  • field-name은 대소문자 구문 없음

헤더 분류

  • Request 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..)
  • Response 헤더: 응답 정보, 예) Server: Apache
  • General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: close
  • Entity 헤더: 엔티티 바디 정보, 예) Content-Type: text/html, Content-Length: 3423

HTTP 표준 변경

  • 1999년 RFC2616 (폐기) -> 2014년 RFC7230~7235 등장
  • 엔티티(Entity) -> 표현(Representation)
  • Representation = representation Metadata + Representation Data
  • 표현 = 표현 메타데이터 + 표현 데이터

HTTP BODY

  • 메시지바디 = payload
  • 표현은 요청이나 응답에서 전달할 실제 데이터
  • 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공

표현 헤더

  • Content-Type: 표현 데이터의 형식
  • Content-Encoding: 표현 데이터의 압축 방식
  • Content-Language: 표현 데이터의 자연 언어
  • Content-Length: 표현 데이터의 길이

표현 헤더는 전송, 응답 둘다 사용

협상(컨텐츠 네고시에이션)

  • Accept: 클라이언트가 선호하는 미디어 타입 전달
  • Accept-Charset: 클라이언트가 선호하는 문자 인코딩
  • Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
  • Accept-Language: 클라이언트가 선호하는 자연 언어

협상 헤더는 요청시에만 사용

협상과 우선순위 

   Quality Values(q)

  • 0~1, 클수록 높은 우선순위, 생략하면 1

      Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

  1. ko-KR;q=1 (q생략)
  2. ko;q=0.9
  3. en-US;q=0.8
  4. en:q=0.7
  • 구체적인 것이 우선한다.

       Accept: text/*, text/plain, text/plain;format=flowed, */*

  1. text/plain;format=flowed
  2. text/plain
  3. text/*
  4. */*
 
  • 구체적인 것을 기준으로 미디어 타입을 맞춘다.
Media Type
 Quality
text/html;level=1
1
text/plain
0.3
image/jpeg
 0.5
text/html;level=2
0.4
text/html;level=3 0.7
text/html;level=1
0.7 

전송 방식

  • 단순 전송      | Content-Length: 3423
  • 압축 전송.     | Content-Encoding: gzip
  • 분할 전송.     | Transfer-Encoding: chunked
  • 범위 전송.     Range:bytes=1001-2000| Content-Range: bytes 1001-2000 / 2000(끝길이)
 

일반 정보

From: 유저 에이전트의 이메일 정보
Referer: 이전 웹 페이지 주소 (referrer의 오타)
User-Agent: 유저 에이전트 애플리케이션 정보
Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보 Date: 메시지가 생성된 날짜

특별한 정보

  • Host: 요청한 호스트 정보(도메인)
  • Location: 페이지 리다이렉션
                         201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
                         3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
                                                         -> 해당 Location으로 자동 이동
  • Allow: 허용 가능한 HTTP 메서드
                         405 (Method Not Allowed) 에서 응답에 포함해야함
                         ex) Allow: GET, HEAD, PUT  
  • Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
                         503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
                         Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
                         Retry-After: 120 (    초단위 표기)

인증

  • Authorization: 클라이언트 인증 정보를 서버에 전달
  • WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

쿠키

  • 예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
  • 사용처
    - 사용자 로그인 세션 관리
    - 광고 정보 트래킹
  • 쿠키 정보는 항상 서버에 전송됨
    - 네트워크 트래픽 추가 유발
    - 최소한의 정보만 사용(세션 id, 인증 토큰)
    - 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고
  • 주의!
    - 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)
  • 생명주기
    - Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
    - Set-Cookie: max-age=3600 (3600초), 0이나 -1일 경우 즉시 삭제
    - 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
    - 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
  • 도메인
    - 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
       domain=example.org를 지정해서 쿠키 생성시, example.org는 물론이고 dev.example.org도 쿠키 접근
    - 생략: 현재 문서 기준 도메인만 적용
       example.org 에서 쿠키를 생성하고 domain 지정을 생략시, example.org 에서만 쿠키 접근, dev.example.org는 쿠키 미접근
  • 경로
    - 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
    - 일반적으로 path=/ 루트로 지정
  • 보안
    1) Secure
       - 쿠키는 http, https를 구분하지 않고 전송
       - Secure를 적용하면 https인 경우에만 전송
    2) HttpOnly
       - XSS 공격 방지
       - 자바스크립트에서 접근 불가(document.cookie)
       - HTTP 전송에만 사용
    3) SameSite
       - XSRF 공격 방지
       - 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

 

저작자표시

'HTTP' 카테고리의 다른 글

HTTP 상태코드  (0) 2022.03.13
HTTP 메서드 활용  (0) 2022.03.06
HTTP 메서드  (0) 2022.03.05
HTTP 기본  (0) 2022.03.01
URI와 웹 브라우저 요청 흐름  (0) 2022.02.24

상태코드 : 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

  • 1xx (Informational): 요청이 수신되어 처리중
  • 2xx (Successful): 요청 정상 처리
  • 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
  • 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
  • 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면?

  • 클라이언트는 상위 상태코드로 해석해서 처리 -> 미래에 상태 코드가 추가되어도 클라이언트 변경하지 않아도 됨

2xx

  • 200 OK.               요청성공 GET
  • 201 Created.       새로운 리소스가 생성됨
  • 202 Accepted    요청이 접수되었으나 처리가 완료되지 않았음. 배치처리 같은 곳에서 사용 or 1시간 뒤에 요청을 처리하는 경우
  • 204 No Content 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음. 웹 문서 편집기에서 save할 경우 결과                               로 아무 내용이 없어도 된다.

3xx

  • 300 Multiple Choices
  • 301 Moved Permanently
  • 302 Found
  • 303 See Other
  • 304 Not Modified
  • 307 Temporary Redirect
  • 308 Permanent Redirect

 

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

  • 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동, 원래의 URL 사용 X, 검색 엔진 등에서도 변경 인지
  • 예) /members -> /users
  • 예) /event -> /new-event
  • 일시 리다이렉션 - 일시적인 변경, 따라서 검색 엔진 등에서 URL을 변경하면 안됨
 
  • 주문 완료 후 주문 내역 화면으로 이동
  • PRG: Post/Redirect/Get
  • 특수 리다이렉션
  • 결과 대신 캐시를 사용

 

영구 리다이렉션 301, 308

  • 301 - 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  • 308 - 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

일시적인 리다이렉션 302, 307, 303

  • 302 Found - 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  • 307 Temporary Redirect - 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
  • 303 See Other - 리다이렉트시 요청 메서드가 GET으로 변경
  • 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
  • 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음

PRG: Post/Redirect/Get - 일시적인 리다이렉션 예시

주문(POST) 후 새로고침하면 재주문(POST) 되면 안된다. 이 경우는, 새로고침 시 GET으로 리다이렉트하여 결과 화면만 조회

 

기타 리다이렉션 300, 304

  • 300 Multiple Choices: 안쓴다.
  • 304 Not Modified : 캐시를 목저으로 사용, 캐시가 수정 안되었으므로 캐시로 리다이렉트 시켜준다. (메시지 바디 포함하면 안됨).                                      조건부로 GET, HEAD 요청시 사용

4xx

  • 400 Bad Request : 요청 구문, 메시지 등등 오류
  • 401 Unauthorized : 인증(Authentication): 본인이 누구인지 확인 (로그인) <-> 인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음), 오류 메시지가 Unauthorized로 나오지만 의미는 Unauthenticted임(아쉬운부분)
  • 403 Forbidden : 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
  • 404 Not Found : 요청 리소스가 서버에 없음 혹은 권한 부족한 클라이언트에게 특정 리소스 숨기고 싶은 경우

5xx

  • 500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류
  • 503 Service Unavailable : 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음. Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

 

저작자표시

'HTTP' 카테고리의 다른 글

HTTP 헤더1 - 일반 헤더  (0) 2022.03.13
HTTP 메서드 활용  (0) 2022.03.06
HTTP 메서드  (0) 2022.03.05
HTTP 기본  (0) 2022.03.01
URI와 웹 브라우저 요청 흐름  (0) 2022.02.24

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

2가지 전달방식

  • 쿼리 파라미터를 통한 데이터 전송

        - GET

        - 주료 정렬 필터(검색어)

  • 메시지 바디를 통한 데이터 전송

        - POST, PUT, PATCH

        - 처리, 리소스 등록, 리소스 변경

 

4가지 상황

  • 정적 데이터 조회

       - 이미지, 정적 텍스트 문서

  • 동적 데이터 조회

       - 주로 검색, 게시판 목록에서 정렬 필터(검색어)

       - GET - query(쿼리 파라미터, 쿼리 스트링) 사용

  • HTML Form을 통한 데이터 전송

       - HTML 액션을 통합 데이터 전송

           1) POST 전송

             Content-Type: application/x-www-form-urlencoded 사용

             form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)

             전송 데이터를 url encoding 처리 

           2) GET 전송

           - 회원 가입, 상품 주문, 데이터 변경

           3) 파일 업로드

            - Content-Type: multipart/form-data

            - 파일 업로드 같은 바이너리 데이터 전송시 사용

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

     참고 : HTML Form 전송은 GET, POST만 지원 

  • HTTP API를 통한 데이터 전송

       - 회원 가입, 상품 주문, 데이터 변경

       - 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

       - Content-Type: application/json을 주로 사용 (사실상 표준),    TEXT, XML, JSON 등등

참고하면 좋은 URI 설계 개념

문서(document)

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

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

컬렉션(collection)

서버가 관리하는 리소스 디렉터리 서버가 리소스의 URI를 생성하고 관리

예) /members

스토어(store)

클라이언트가 관리하는 자원 저장소 클라이언트가 리소스의 URI를 알고 관리

예) /files

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

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행 동사를 직접 사용
예) /members/{id}/delete

 

저작자표시

'HTTP' 카테고리의 다른 글

HTTP 헤더1 - 일반 헤더  (0) 2022.03.13
HTTP 상태코드  (0) 2022.03.13
HTTP 메서드  (0) 2022.03.05
HTTP 기본  (0) 2022.03.01
URI와 웹 브라우저 요청 흐름  (0) 2022.02.24

API URI 설계

좋은 URI 설계란 ? 리소스 식별이 가장 중요하다.

즉, 리소스와 행위를 분리

  • 리소스 - 명사 - 회원
  • 행위 - 동사 - 조회, 등록, 삭제, 변경
 

URI는 리소스만 식별

HTTP 메서드 종류

주요 메서드

  • GET: 리소스 조회
  • POST: 요청 데이터 처리, 주로 등록에 사용
  • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH: 리소스 부분 변경
  • DELETE: 리소스 삭제

기타 메서드

  • HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
  • OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
  • CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
  • TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

주요메서드 분석

GET

  • 리소스 조회
  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)으로 전달
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
    request
    /members/100
    response
    GET /members/100 HTTP/1.1
    Host: localhost:8080
    {
       "username": "young",
       "age": 20
    }
    HTTP/1.1 200 OK
    Content-Type: application/json
    Content-Length: 34
    {
       "username": "young",
       "age": 20
    }

post

  • 요청 데이터 처리
  • 메시지 바디를 통해 서버로 요청 데이터 전달
  • 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
request
 /members -> /members/100
신규 리소스 식별자 생성
response
POST /members HTTP/1.1
Content-Type: application/json
{
   "username": "young",
   "age": 20
}
{
   "username": "young",
   "age": 20
}
 
HTTP/1.1 201 Created
Content-Type: application/json \
Content-Length: 34
Location: /members/100
{
   "username": "young",
   "age": 20
}

POST처리에 정해진 것이 없다 -> 리소스 URI에 POST 요청이 오면 요청 데이터틑 어떻게 처리할지 리소스마다 따로 정해야 한다

 

주로, 다음과 같은 경우에 많이 사용한다.

  1. 새 리소스 생성(등록)
  2. 요청 데이터 처리
  3. 다른 메서드로 처리하기 애매한 경우

put

  • 리소스 대체(있으면 대체 : 전체 삭제후 생성 / 없으면 생성)
  • 클라이언트가 리소스를 식별(URI 지정)
request
 /members/100
(1) 생성
PUT /members/100 HTTP/1.1
Content-Type: application/json
{
   "username": "young",
   "age": 20
}
(2) 리소스 완전 대체
PUT /members/100 HTTP/1.1
Content-Type: application/json
{
   // username 없음
   "age": 50
}
(1) 생성
{
   "username": "young",
   "age": 20
}



(2) 리소스 완전 대체
{
   // username 삭제
   "age": 50
}

patch

  • 리소스 부분 변경 (put과의 차이)
request
 /members/100
 
PATCH /members/100 HTTP/1.1
Content-Type: application/json
{
   // username 없음
   "age": 50
}
{
   "username": "young",
   "age": 20
}

 리소스 부분 변경

{
   "username": "young",
   "age": 50
}

delete

request
 /members/100 리소스 제거
DELETE /members/100 HTTP/1.1
Host: localhost:8080
 
x

 

HTTP 메서드의 속성

안전(Safe Methods)

  • 호출해도 리소스를 변경하지 않는다

멱등(Idempotent Methods)

  • 한번 호출하든 두번 호출하든 결과가 똑같다.
  • GET, PUT, DELETE (POST x)
  • 자동 복구 메커니즘에 활용 가능 : 서버 Time out 등르로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시해도 되는가? 판단 근거, 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다

캐시가능(Cacheable Methods)

  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 캐시가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용, POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

HTTP웹_기본지식_20201226 출처: https://ko.wikipedia.org/wiki/HTTP

저작자표시

'HTTP' 카테고리의 다른 글

HTTP 상태코드  (0) 2022.03.13
HTTP 메서드 활용  (0) 2022.03.06
HTTP 기본  (0) 2022.03.01
URI와 웹 브라우저 요청 흐름  (0) 2022.02.24
인터넷 네트워크  (0) 2022.02.15

HTTP : HyperText Transfer Protocol

  • HTML, TEXT
  • IMAGE, 음성, 영상, 파일
  • JSON, XML (API)
  • 거의 모든 형태의 데이터 전송 가능
  • 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

클라이언트 - 서버

Request - Response 구조

Stateful, Stateless

상태유지

 - 항상 같은 서버가 유지되어야 한다.

 - 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지, 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지

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

무상태

 - 아무 서버나 호출 가능하다. 무한한 서버 증설 가능 (Scale out - 수평확장에 유리)

 - 서버 개발자가 가장 어려워 하는 부분 - 같은 시간에 딱 맞추어 대규모 트래픽이 발생하는 것을 해결하기 위해 적절히 필요

Connectionless

HTTP는 기본이 비연결성(connectionless)

한계

  • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드

극복

  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
  • HTTP/2, HTTP/3에서 더 많은 최적화

HTTP 메시지

<요청 메시지>

start-line = request-line / status-line
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

  • method 종류 : GET, POST, PUT, DELETE...
  • request target : absolute-path[?query] (절대경로[?쿼리])  참고) *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.
  • HTTP-version : ex) HTTP/1.1

ex) GET /search?q=hello&hl=ko HTTP/1.1

       Host: www.google.com

 

<응답 메시지>

start-line = request-line / status-line
status-line = HTTP-version SP status-code SP reason-phrase CRLF

  • HTTP-version : ex) HTTP/1.1
  • status-code : HTTP 상태코드 - 요청 성공, 실패를 나타냄 ex) 200 성공, 400 클라이언트 요청 오류, 500 서버 내부 오류

ex) HTTP/1.1 200 OK

     Content-Type: text/html;charset=UTF-8 Content-Length: 3423

     

      <html> <body>...</body>

     </html>

 

HTTP 헤더 / 메시지 바디

HTTP 헤더

  • HTTP 전송에 필요한 모든 부가정보
  • header-field = field-name ":" OWS field-value OWS.    (OWS : Optional WhiteSpace : 띄어쓰기 허용)
  • field-name은 대소문자 구문 없음

       ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 캐시 관리 정보 ...

             (표준 헤더가 너무 많음, 필요시 임의의 헤더 추가 가능 - hellowordl:hi)

HTTP 메시지 바디

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

< 요청 메시지 예제>

요청 메시지 GET /search?q=hello&hl=ko HTTP/1.1
HTTP 헤더 Host: www.google.com

< 응답 메시지 예제>

응답 메시지 HTTP/1.1 200 OK
HTTP 헤더 Content-Type: text/html;charset=UTF-8
Content-Length: 3423
HTTP 메시지 바디 <html> <body>...</body>
</html>
 

HTTP는 단순핟고 확장가능한 기술이다.

저작자표시

'HTTP' 카테고리의 다른 글

HTTP 상태코드  (0) 2022.03.13
HTTP 메서드 활용  (0) 2022.03.06
HTTP 메서드  (0) 2022.03.05
URI와 웹 브라우저 요청 흐름  (0) 2022.02.24
인터넷 네트워크  (0) 2022.02.15

URI(Uniform Resource Identifier) :  자원을 식별하는 통일된 방식

  • URL(Resource Locator)
  • URN(Resource Name)

 

 

 

URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화  되지 않아 URL을 보통 URI로 사용한다.

  foo://example.com:8042/over/there?name=ferret#nose                                - URL

   \_/    \________________/\_________/ \_________/   \__/

     |                      |                           |                     |               |

   scheme     authority                path             query   fragment
      |   _____________________|__

     /\   /                                              \

  urn:example:animal:ferret:nose                                                                         - URN

 

 

URL

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

   ex ) https://www.google.com:443/search?q=hello&hl=ko

  •         -  프로토콜(https)
  •         -  호스트명(www.google.com) - 도메인명 또는 IP주소
  •         -  사용자정보 - 거의 사용하지 않음
  •         -  포트 번호(443) - 일반적으로 생략, 디폴트로 http 80, https 443 
  •         -  패스(/search) - 경로, 계층적 구조
  •         -  쿼리 파라미터(q=hello&hl=ko) - key=value 형태, ?로 시작, &로 추가, 웹서버에 제공하는 파라미터, 문자형태,
  •             query string으로도 불림
  •         -  fragment - html 내부 북마크 등에 사용, 서버에 전송 안함. (->자세히는 나중에)

 

웹 브라우저 요청 흐름

 

1) URL을 분석해 HTTP 메시지를 만든다
2) 인터넷 네트워크 편에서 설명한 것처럼 HTTP 메시지에 TCP/IP 패킷이 붙고 Ethernet Frame도 씌워진다.
3) 요청 패킷 전달
4) 요청 패킷 도착
5) 응답 메시지도 요청 메시지와 동일하게 HTTP 메시지에 TCP/IP 패킷이 붙고 Ethernet Frame도 씌워져 전달된다
6) 응답 패킷 전달
7) 응답 패킷 도착

 

8) 응답 받은 메시지 렌더링

저작자표시

'HTTP' 카테고리의 다른 글

HTTP 상태코드  (0) 2022.03.13
HTTP 메서드 활용  (0) 2022.03.06
HTTP 메서드  (0) 2022.03.05
HTTP 기본  (0) 2022.03.01
인터넷 네트워크  (0) 2022.02.15

인터넷 프로토콜 스택의 4계층 (TCP/IP 4계층)

계층 프로토콜 종류
애플리케이션 HTTP, FTP
전송 TCP, UDP
인터넷 IP
네트워크
인터페이스 		 LAN 드라이버, LAN 장비

송신시 동작 순서

각 Layer에서 저장되는 정보

3-way-handshake

   - 데이터 전송전 연결을 확인한다.

  1. 접속요청 : SYN   ->
  2.                            <- ACK+SYN : 요청 수락 + 접속요청
  3. 요청수락 : ACK   ->
  4. 데이터 전송 (참고 : 3.ACK와 함께 데이터 전송 가능)

TCP와 UDP 차이

  TCP UDP
연결지향  연결지향 - 3 way handshake (가상 연결) x, 기능이 거의 없음
데이터 전달 보증 데이터 전달 보증 x
순서 보장 (packet 1, 2, 3 -> 1, 2, 3) 순서 보장 x
신뢰성 신뢰할 수 있다 x
속도 느림 빠름
     
결론 현재는 대부분 TCP 사용 IP와 거의 같다. + port + 체크섬 정도만 추가
애플리케이션에서 추가작업 필요.

PORT

  • 같은 IP 내 프로세스 구분 ( 서버에 두개의 애플리케이션이 띄워져 있고 두개의 애플리케이션에 접근하고자 한다면 Port를 이용해 구분하여 붙을 수 있다 )
  •  따라서 TCP 세그먼트에 출발지, 목적지 PORT 추가.

DNS

  • Domain Name System
  • IP 기억하기 어려우니 사용

 

 

 

<참고> 

해당 포스팅은 인프런의 김영한님이 강의하신 HTTP 강의 를 수강하고, 이해를 정리한 기록들이며 모든 자료의 출처는 강의의 강의자료이다.

저작자표시

'HTTP' 카테고리의 다른 글

HTTP 상태코드  (0) 2022.03.13
HTTP 메서드 활용  (0) 2022.03.06
HTTP 메서드  (0) 2022.03.05
HTTP 기본  (0) 2022.03.01
URI와 웹 브라우저 요청 흐름  (0) 2022.02.24

+ Recent posts

티스토리툴바