HTTP (Hypertext Transfer Protocol)

교수님 이야기..

대학원, html 공부
과연 홈페이지가 만들어질까?
교수님들 회의 - 홈페이지 만들어야할까?
공대교수님들은 만들어야한다.
다른 교수님 컴퓨터 일상화x 누가 그걸보겟냐
-------------------------------------------------
오프라인 통장이 사라지고있다.
은행없이 거래가 가능한 시스템을 목표로

거래를 은행이 인증을 해준다.
지금은 은행이라는 기관이없으면 거짓말을 할수있지만.
블록체인 인증이 되면. 전세계인들이 인증 해주는 효과.

-------------------------------------------------------------

 

 

< HTTP >

- 하이퍼텍스트 전송 프로토콜

- Hypertext Transfer Protocol

- 월드 와이드 웹에서 데이터를 액세스하는 데 주로 사용되는 프로토콜

- 평문(plaintext), 하이퍼텍스트, 오디오, 영상 등의 형태로 데이터를 전송

- 문서간의 빠른 이동이 가능한 하이퍼텍스트 환경에서의 효율성

 

< HTTP의 기능 >

- FTP와 SMTP의 조합과 유사

- 파일을 전송하고 TCP의 서비스를 사용

- 하나의 TCP 연결만을(잘 알려진 포트 80) 사용

- 별도의 제어 연결 없이, 데이터만 클라이언트와 서버 사이에 전송

- 클라이언트와 서버 사이에 전송되는 데이터가 SMTP 메시지와 유사하게 보임

- 메시지의 형식이 MIME과 유사한 헤더에 의해 제어  //MIME = 멀티미디어 데이터 전송하기위한..

Ü메시지가 클라이언트와 서버 사이에 양방향으로
전송된다는 점에서 SMTP와 다름

ÜSMTP 메시지는 사람이 읽지만, HTTP 메시지는 HTTP 서버와 HTTP 클라이언트(브라우저)에 의해 읽혀지고 해석

ÜSMTP 메시지는 저장된 후 전달되지만,
HTTP 메시지는 즉시 전달

 

http 통신은 커넥틀리스 / 연결하자마자 보내고 빨리 끊는다.

파일 전송 시스템과 유사하다. (방식은 조금 다르지만)

 

----------------------------------------------------------------------------------------------------------

오라클  - DB에서 인설트해서 셀렉트해서 쿼리를보고, 수정을한다... -> 완료를 누르면 DB에 적용

메모리에서 작업을했다가 , 완료를 눌러야 DB에 적용 및 저장

마지막에 submit 를 꼭 해야 완료가된다. -> '트랜잭션' 

한 페이지 들어가는데만 해도 수 많은 트랜잭션이 일어난다. -> 패킷 분석해서 확인해보자

----------------------------------------------------------------------------------------------------------

 

< 클라이언트와 서버 사이의 HTTP 트랜잭션 >

- TCP의 서비스를 이용하지만, HTTP 자체는 상태가 존재하지 않는(stateless) 프로토콜

 

 

하나의 페이지를 보는데 수많은 트랜잭션 / 즉 수많은 패킷이 잡히는것을 볼 수 있다. 

정상적인 핸드쉐이킹이 이루어지지 않는다.

 

< HTTP의 메시지 분류 >

- 두 가지 일반적인 유형의 메시지 존재

메세지 유형

 

HTTP 메시지 예

< 요청 메시지 구성 >

- 요청 라인, 헤더, 본문으로 구성

 

 

요청 메세지 구성

헤더가 쭉쭉오다가 빈 줄이있다 -> 바디로 넘어간다.

 

< 요청 라인 >

- 요청 유형(메소드), 자원(URL), HTTP 버전 등을 정의

- 요청 유형, 공백, URL, 공백, HTTP 버전으로 구성

 

- 요청 유형(request type)

     HTTP 버전 1.1에서는, 여러 가지 요청 유형들이 정의

     요청 메시지를 여러 가지 메소드(method)로 분류

 

- URL(Uniform Resource Locator)

    웹 페이지를 액세스하기 원하는 클라이언트는 주소

    HTTP는 위치 지정자(locator)라는 개념 사용

    인터넷에서 어떤 종류의 정보든 지정할 수 있는 표준

    메소드, 호스트 컴퓨터, 포트, 경로의 네 가지 부분 정의

    메소드는 문서를 검색하는 데 사용되는 프로토콜

          - 고퍼(Gopher), FTP, HTTP, News, TELNET 등 존재

- 버전(version)

   현재 대부분의 HTTP 버전이 1.1이지만 1.0과 0.9도 사용

 

- 호스트는 정보가 위치하고 있는 컴퓨터

     웹 페이지들은 보통 컴퓨터에 저장되어 있고,
     컴퓨터는 보통 “www”란 글자로 시작되는 별칭을 가짐

     웹 페이지를 갖고 있는 컴퓨터에 주어진 어떤 이름도 가능

- URL에 서버의 포트 번호를 사용하는 것은 선택

     포트가 포함된다면 이는 호스트와 경로 사이에 위치해야 함

     콜론을 사용해 호스트와 분리

- 경로는 정보가 위치하고 있는 파일의 경로 이름

     UNIX 운영 체제에서 경로는 서브 디렉터리와 파일들을
     디렉터리로부터 분리하는 사선을 사용한다는 점을 유념

 

   리눅스는 대,소문자 정확히 구분한다 <-> 윈도우는 그렇지 않다.

 

< URL(Uniform Resource Locator) >

- 전세계의 문서들을 접근하기 위해 HTTP가 제공하는 위치 지정자

- 프로토콜(Method)

     문서를 가져오기 위해 사용하는 프로토콜 명시(ftp, telnet, http)

- 호스트 주소

     요청 정보가   위치해 있는 시스템의 주소(ip or domain name)

- 포트번호

    접근하려는 서버의 포트번호 지정 가능

< 메소드의 목적 >

- 메소드라는 여러 종류의 메시지 정의

- 요청 메소드는 클라이언트가 서버에게 보내는 실제 명령이거나 요청

- GET

    클라이언트가 서버로부터 문서를 읽어오기 원할 때 사용

    문서의 주소는 URL에 정의

    문서를 검색하는 주요 메소드

    서버는 오류가 없는 경우 보통 응답 메시지의 본문에 문서의 내용을 담아서 응답

- HEAD

    클라이언트가 문서 자체가 아니라 문서에 대한 어떤 정보를 원할 때 사용

    GET과 비슷하지만 서버로부터의 응답에 본문이 없음

 - POST

    클라이언트가 서버에게 어떤 정보를 제공할 때 사용

    서버에게 입력을 보내는 데 사용될 수 있음

- PUT

   클라이언트가 서버에 저장될 새 문서 혹은 교체 문서를 제공하기 위해 사용

   문서는 요청의 본문에 포함되고 URL에 의해 지정된 위치에 저장

 

클라이언트 -> 서버 데이터 보낼 때.     ex) ID를 넘겨줄 때.

GET 방식은 URL뒤에다가 정보를 달아서간다.  //뒤에 %로나오는것은 한글일때. (아스키코드값이라서 한글 못나타냄) 

POST 방식 - HTTP 메세지 안에 들어간다. -> URL에 표시가 안 된다.   

Wire Shark로 보면 다 보인다.. (캡처 해서 분석하면 다 보인다. http는 암호화 전송이 아니다. )

아이디나 패스워드를 적어야하는 페이지는 https로 바꿔서 만든다.

// http인데 아이디, 패스워드를 기입하라는 사이트가 있으면 의심해 봐야한다.

 

- PATCH

     PUT과 비슷하나 요청이 기존 파일에서 구현되어야 하는 변경사항의 목록만 포함

- COPY

     파일을 다른 위치로 복사하기 위해 사용

     원본 파일의 위치는 요청 라인(URL)에서 주어지고 목적지의 위치는 항목 헤더에서 주어짐

- MOVE

     파일을 다른 위치로 이동하기 위해 사용

     원본 파일의 위치는 요청 라인(URL)에서 주어지고 목적지의 위치는 항목 헤더에서 주어짐

- DELETE

     서버에서 문서를 제거하기 위해 사용

- LINK

     문서에서 다른 위치로 링크나 링크들을 생성하기 위해 사용

     파일의 위치는 요청 라인(URL)에서 주어지고 목적지의 위치는 항목 헤더에서 주어짐

- UNLINK

     LINK 메소드에 의해 생성된 링크를 삭제하기 위해 사용

- OPTION

     클라이언트가 서버에게 사용 가능한 옵션을 질의하기 위해 사용

 

 

< 응답 메시지 구성 >

- 상태 라인, 헤더, 본문으로 구성

응답 메세지 구성

 

 

< 상태 라인 >

- 응답 메시지의 상태를 정의

- HTTP 버전, 공백, 상태 코드, 공백, 상태 문구로 구성

- 버전(version)

    요청 라인 필드와 동일

    현재 대부분의 HTTP 버전이 1.1이지만 1.0과 0.9도 사용

 

< 상태 코드(status code) >

- 필드는 FTP와 SMTP 프로토콜에 있는 것과 유사

- 세 자리 숫자로 구성

     100 범위의 코드들은 단지 정보 차원

     200 범위의 것들은 요청이 성공적임을 나타냄

     300 범위의 코드들은 클라이언트를 또 다른 URL로 재지정

     400 범위의 코드들은 클라이언트 사이트에서의 오류를 나타냄

     500 범위의 코드들은 서버 사이트에서의 오류를 나타냄

 

300: 클라이언트가 서버에 없는 자료를 달라고할때

500: 서버쪽 오류

 

- 상태 문구(status phrase)

    문자 형태로 상태 코드 설명

 

< 상태 코드와 상태 문구 >

 

 

< 헤더 >

- 클라이언트와 서버 사이에 추가적인 정보 교환

      클라이언트가 특별한 형식으로 문서가 전송되도록 요청할 수도 있고,

      또는 서버가 문서에 대한 추가적인 정보를 전송할 수도 있음

- 한 줄 이상의 헤더라인이 될 수 있음

      각 헤더 라인은 헤더 이름, 콜론, 공백, 헤더 값으로 구성

< 헤더 라인 >

- 네 가지 분류

    일반 헤더, 요청 헤더, 응답 헤더, 항목 헤더

    요청 메시지는 일반, 요청, 항목 헤더만 포함 가능

    응답 메시지는 일반, 응답, 항목 헤더만 포함 가능

< 일반 헤더 >

- 메시지에 대한 일반적인 정보를 제공

- 요청과 응답에 모두 존재 가능

< 요청 헤더 >

- 요청 메시지에만 존재 가능

- 클라이언트의 구성과 클라이언트가 선호하는 문서 형식을 지정

< 응답 헤더 >

- 응답 메시지에만 존재 가능

- 서버의 구성과 요청에 대한 특별한 정보 지정

< 항목 헤더 >

- 문서의 본문에 대한 정보 제공

- 주로 응답 메시지에 존재

- POST나 PUT 메소드와 같이 본문을 포함하는 몇 가지 요청 메시지 또한 이러한 종류의 헤더 사용

< HTTP 요구 메시지 >

- 「Info」열에 「GET/sample.html HTTP/1.1」이라고
 표시된 12번 프레임이 HTTP 요구 메시지를 포함한 패킷

 

실습을 해 봅시다!