HTTP / 웹통신 URL, Message 형식, 통신 규약, 구조

목차

1. HTTP 개요

1) HTTP란 무엇인가?

2) HTTP의 기본 구조

 

2. HTTP URL

1)url 설명

2)URL, URI, URN의 차이

URL (Uniform Resource Locator)

URI (Uniform Resource Identifier)

URN (Uniform Resource Name)

 

3. HTTP 통신 규약

1) HTTP의 기본 통신 방식

-Connectionless

-Stateless

 

 

4. HTTP  message 형식

- start line  

1) request line  사용자

2) status line  응답/서버

 

 

위키백과

 

1. HTTP 개요

1) HTTP란 무엇인가?

HTTP (Hyper Text Transfer Protocol)는 웹 페이지 데이터를 전송하기 위해 사용되는 프로토콜. 웹에서 데이터를 주고받을 때, 클라이언트와 서버 간의 통신을 위한 규약. HTTP는 텍스트(HTML, JSON 등)로 구성된 데이터를 신뢰성 있게 전달.

뼈대

2) HTTP의 기본 구조

• Header: 요청 또는 응답을 처리하는 데 필요한 정보가 포함됩니다. 여기에는 HTTP 통신에 필요한 설정 정보와 메타데이터가 담겨 있습니다.
• blank
• Body: 실제 웹 데이터(HTML 등)가 포함된 부분으로, 클라이언트에게 전달되는 데이터입니다.

 

2. HTTP HTTP URL

1)url 설명

  http : // http://www.google.com : 80

= URL

---

 이게 정석이다. 구글 서버에 있는 저 위치의 정보를 불러온다. >>

http : //ID:password@http://www.google.com : 80 / page 이름이나 경로

WEB 서비스는 기본 익명 접속을 지원, 허용한다

만약 내가 아이디,비번을 입력해야 웹서비스 접속을 할 수 있게 
만들면 입력해야만 하게 만들 수 있음.
로그인 시스템이 있음.
설정을 안 하면 익명으로 자동으로 들어감.

 

 

기본적으로 생략해도 브라우저에서 자동으로 넣어주므로 서버주소만 적어줘도 된다.

---

2)URL, URI, URN의 차이

URL = L이 location임. 위치 정보. 
URN = N이 name임. 이름정보를 통해 불러온다.
-> URI라고도 한다. 실제 의미는 이게 맞음!

 

 

 

 

인코딩과 비슷한 것 -> 인크립션

 

인코딩과 유사한 방식으로 데이터를 변환하지만, 보안을 강화하기 위한 기술 "암호화(Encryption)"

암호화는 데이터를 특정 알고리즘을 사용하여 변환하며, 이를 복호화(Decryption)해야 원래 형태로 되돌릴 수 있다.

 

3. HTTP 통신 규약

1) HTTP의 기본 통신 방식

• Connectionless: 각 HTTP 메시지는 별개의 연결을 통해 전달. 여러 페이지 요청을 하더라도 매번 새로운 연결을 시도  -> keep-alive
• Stateless: HTTP는 클라이언트의 이전 상태 정보를 유지하지 않습니다. 이로 인해 동적인 서비스에서 상태 관리가 필요. 이를 해결하기 위해 -> Cookie나 Session 등의 기술이 사용.

 

conectionnless를 사용하는 이유는 클라이언트가 웹에서 요청을 하고 응답을 받았으면 연결을 계속 하고 있으면 서버에 부담이 많이 생기니까 연결을 끊는다. 왜냐하면 웹은 불특정다수가 이용하므로 자원소모를 줄이는 게 좋음. 다만 연결을 다시 할 때마다 3way handshake를 해야한다는 점은 있음.

statelelss는 connectionless가 불러온 것. 

예를 들어 내가 서버에 로그인 페이지를 요청함. 서버는 요청한 페이지를 주고 로그인에 성공. 근데 커넥션리스이므로 페이지가 새롭게 바뀔 때마다 연결이 끊김. 난 로그인에 성공했으니까 메일페이지를 요청함. 하지만 서버는 이미 새롭게 연결된 상태이므로 네가 뭔데??라는 입장이 된다. 메일에 들어가려면 로그인에 성공한 사람이어야 하는데 그걸 알길이 없음.

 

그래서 생긴게 keep-alive 기능이 생겼다. 이는 지속적 연결기능이다.

Keep-Alive는 HTTP에서 지속적인 연결(Persistent Connection)을 유지하기 위한 기능.

Keep-Alive 요청이 발생하는 경우

• 웹 브라우저가 여러 개의 리소스를 요청할 때 예를 들어, HTML 페이지를 요청하면 CSS, JavaScript, 이미지 등의 추가 리소스를 가져와야 하는데, Keep-Alive를 사용하면 같은 TCP 연결을 유지한 채 여러 개의 요청을 처리할 수 있습니다.
• API 호출이 많을 때 REST API를 호출하는 경우, 매번 새로운 연결을 생성하는 것보다 기존 연결을 유지하는 것이 성능 면에서 더 효율적입니다.
• HTTP/1.0에서 명시적으로 요청할 때 HTTP/1.0에서는 Connection: Keep-Alive 헤더를 포함해야 지속적인 연결이 가능합니다.

 

로그인 했을 때 이 사람이 누구인지 구분하기 위해 생겼다.
 ip는 공인 ip를 다수가 이용하면 구분 x, port는 매번 바뀌므로 이 사람인지 알 수가 x

인터넷 기록 삭제할 때 뜨는 쿠키

->cookie라는 값이 나왔다.

cookie값을 보고 사용자를 구분한다.

근데 이건 로그인을 하든 안 하든 종합적으로 저장한 정보이다.

내 기록, 로그인 정보, 7일동안 보지 않기 등등 -> 내 쿠키값은 브라우저에 저장이 된다. 브라우저에서 쿠키값을 지우면 다 지워짐. 내 브라우저의 로컬 디바이스 기기에 정보가 저장이 되며 내가 브라우저에 접속을 하면 브라우저는 쿠키를 보고 서버에 전달함. 

상태정보를 구분하기 위한 식별값.

 

 

4. HTTP  message 형식

 

wireshark로 본 HTTP 프로토콜

 

http header request와 http response가 서로 조금 다르다.

header의 첫번 째 줄을 start line이라고 하는데 해당 정보는 항상 필수적으로 들어가는 설정 정보

두번째 줄부터는 message header 값- request 혹은 response에 따라 다르다.

 

첫 번째 줄 - start line

1. request line

2. status line 

 

두번째 줄- message header - 응답의 코드와 응답의 설명 

1. GeneralHeader - 요청 응답과 상관없이 들어가는 통신에 필요한 설정 정보

2. Request Header - 요청 시에만 들어가는 설정 정보

3. Response Header - 응답 시에만 들어가는 정보

4. entity header- body에 들어간 web date의 추가 정보 (body의 크기, 종류, 인코딩 방식, 압축 여부 등등)

 

---

 

start line 

1. request line = 사용자

 

 

요청의 종류와 요청하는 페이지 경로

1.1 매소드 -> 요청의 종류 (무조건 대문자로)

1.2 자원경로 -> 요청하는 페이지나 자원의 경로 /이름,주소

1.3 버전 정보 -> 요청하는 http 프로토콜의 버전

 

ex. GET / HTTP/1.1

get - 메소드 / - 기본 페이지  경로 http- 버전 정보

ex. GET /test.html HTTP/1.1

 

1.1 메소드 종류: GET, POST, HEAD, TRACE, PUT, DELETE 

---------

 

GET: 주소에 해당하는 페이지 요청 : 페이지 요청 시 사용자 입력값을 URL에 포함시켜 전달

URL에 포함된 사용자 입력값: parameter (매개변수)

parameter는 URL에서 사용하는 메타문자와 충돌하는 것을 방지하기 위해 특정 기호들을 URL 인코딩한다.

단순 페이지 요청 시에 많이 쓰고 사용자가 입력한 값이 노출되어도 상관없을 때

 

POST: 주소에 해당하는 페이지 요청 : body에 사용자가 입력한 값을 노출하지 않고 전달

사용자가 입력한 값을 body에 담아서 전송을 하는데 결국은 네트워크 상에서 데이터 자체는 노출되므로 완벽한 보안이 힘들다

그래서 POST방식으로 사용자가 입력한 값을 전달하면서 암호화 통신을 통해 네트워크 상 노출되지 않도록 구현.

 

HEAD: 하댕 페이지를 요청할 때 응답의 header만 받고 싶을 때 해당 자원의 메타정보인 설정정보를 획득

서버와 연결 여부 링크의 유효성 검사

 

TRACE: 전달된 요청을 응답의 body에 담아 응답하기를 요청

 

HTTP: 통신상 무결성 검사

 

PUT: 원거리에서 요청을 통해 웹자원을 생성하는 경우

 

DELETE: 원거리에서 요청을 통해 웹자원을 삭제하는 경우 사용

 

OPTIONS: 서버에서 현재 지원하는 메소드 종류 요청

 

---

 

start line

2. status line = 서버

 

2.1 버전 정보

2.2 응답코드

2.3 응답설명

 

ex. HTTP/1.1 200 OK

 

 

 

---------

2번째 줄 

message header

 

- GeneralHeader

-Request Header

-Response Header

-Entity Header - body안에 있는 정보를 미리 알려주는 것

 

 

***

- GeneralHeader

Connection -지속적인 연결을 하고 싶을 때, TCP 연결

 

-Request Header

Cookie-요청을 보낼 때마다 쿠키값이 계속 전달이 된다.

Host- 가상 호스트 기능 도메인 주소가 들어감

 

 

Referer- 자원 요청 시 어느 위치, 어느 페이지에서 현재 페이지 요청하는지 알려주는 값

이유 1. 운영 : 사용자가 어떤 페이지를 요청할 때 어느 위치에서 요청하는지를 보고 사용자의 웹페이지 분석을 보고, 디테일하게 운영을 하기 위함이다. 특정 사이트에서 넘어오는 사람이 많다고 하면, 그 사이트에서 더 들어올 수 있게 투자를 한다거나..

2. 보안 : 이상한 페이지에서 접속을 시도해도 알 수가 있음. 잘못된 경로로 유입된 얘들을 차단할 때 쓰기도 함.

 

클라이언트가 서버에 만들어서 보내는 정보

해커입장에서는 변조를 해서 보내는 게 가능하다. 서버는 알 수가 없음.

 

-Response Header

 

server- 서버가 자신의 프로그램 정보를 클라이언트한테 알려줌. 왜냐햐면 클라이언트가 웹을 열때 서로 호환이 되는지 알아야 하기 때문에. 해커입장에서는 아주 좋은 정보. 

set-cookie - 서버가 클라이언트한테 주는 쿠키. 처음에만 주는 것.

서버가 클라이언트(웹 브라우저)에게 쿠키를 설정하도록 지시하는 역할. 이를 통해 웹사이트는 사용자의 로그인 상태, 설정, 세션 정보를 유지.

 

 

-Entity Header

 

Content-Length: 크기가 만약 1G로 크면 한번에 보낼 수가 없다. 그래서 나눠서 보내는데 클라이언트 입장에서는 얼만큼 오는지 알 수 없음. 그래서 엔티티 헤더에 정보를 넣어 알려주는 것!

 

 

---

+++

위치를 지정해서 검색하고 싶을 때