23.3.16 DevOps 8일차

< URL과 ULI >

주소창에 입력한 URL = 서버가 제공되는 환경에 존재하는 파일의 위치

https://codestates.com:443/ 사이트에 접속하면 codestates.com 주소가 가리키는 서버의 기본 폴더를 뜻함

무슨말인지 모르겠음..

크롬 부라우저를 파일 탐색기로 사용 가능

URL

• Uniform Resource Locator, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냄.
• scheme, hosts, url-asth로 구분
  [ ⓒ 코드스테이츠 UR클레스 ]

< IP, Port >

• 특정 PC의 주소 = IP address(Internet Protocol address, IP 주소)
• PORT(포트) = IP주소에 진입할 수 있는 정해진 통로
• 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 덩이의 숫자로 구분(= IPv4, Internet Protocol version 4)

터미널에서 nslookup을 이용해 IP주소를 확인 가능

• IPv4는 0-255까지 나타낼 수 있음(43억 개의 IP주소 표현 가능, 이미 용도가 정해진 것도 있음 반드시 기억해야 함)

  • localhost, 127.0.0.1 : 현재 사용중인 로컬 pc
    loopback 주소라고도 부름, IPv6에서는 "::1"로 사용
  • 0.0.0.0, 255.255.255.255 : broadcast address,로컬 네트워크에 접속된 모든 장치와 소통하는 주소(서버에서 접근 가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버 접근 가능)

• IPv4와 IPv6의 차이

  • IPv4 = 32비트 길이의 주소 체계 사용(4바이트 주소), 주소의 한정으로 고갈 문제 발생중
  • IPv6 = 128비트 길이의 주소 체계 사용(16바이트 주소), IPv4의 한계를 극복하기 위해 개발(더 많은 주소), 보안성 기능도 개선
  • IPv4는 점으로 구분된 4개의 숫자로 구성된 32비트 주소, IPv6는 콜론으로 구분된 8개의 16진수 128비트 주소
  • IPv6는 자동으로 구성되는 주소, 모바일 IP 지원, 패킷 헤더의 크기 감소, 향상된 기능

  
  
  

< 포트 >

• '주소:포트' 형식을 사용(ex. qookqook:80)

• 컴퓨터나 네트워크 기기에서 프로세스와 프로세스 사이의 통신을 위해 사용되는 번호

• 16비트 숫자로 표현, 0-65535까지의 범위

• 포트 번호는 TCP/IP 프로토콜에서 사용

  • 21번 포트 (FTP): 파일 전송 프로토콜(FTP)에서 사용

  • 22번 포트 (SSH): 안전한 셸(Shell) 연결을 위해 사용, 리눅스 및 유닉스 기반 시스템에서 원격 로그인을 위해 사용됩

  • 25번 포트 (SMTP): 이메일을 보내기 위한 Simple Mail Transfer Protocol(SMTP)에서 사용

  • 80번 포트 (HTTP): 웹 서버에서 일반적으로 사용되는 포트, Hypertext Transfer Protocol(HTTP) 요청에 사용

  • 443번 포트 (HTTPS): 보안 소켓 계층(SSL)을 통해 암호화된 HTTP 요청을 처리하기 위해 사용

  • 3306번 포트 (MySQL): MySQL 데이터베이스 서버에서 사용

  • 3389번 포트 (RDP): 원격 데스크톱 프로토콜(RDP)을 사용하여 원격으로 다른 컴퓨터에 로그인하기 위한 포트

더 많은 포트
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

< 도메인과 DNS >

< Domain name >

택시에 탑승 후 '대전광역시 서구 둔산로 100 으로 가주세요', '대전 시청 가주세요' 이야기 하면 택시 기사님께서 당연하게 시청으로 움직여 주신다. 이와 같이 도메인 이름을 통해 한눈에 파악하기 IP 주소를 보다 분명하게 나타낼 수 있음.

• IP주소는 3.38.75.3, 15.165.196.64, 3.39.15.29, 43.200.107.223
• 도메인 이름은 codestates.com

< DNS >

모든 IP주소가 도메인 이름을 가지는 것은 아님.
로컬PC 도메인을 제외, 다른 모든 도메인의 이름은 일정 기간 동안 대여하여 사용.
그럼 대여한 도매인과 IP주소는 어떻게 매칭하는가?

DNS = Domain Name System, 호스트 도메인의 이름을 IP주소로 변환하거나 번대의 경우를 수행하는 데이터베이스 시스템
(naver.com을 검색하면 DNS에서 IP주소 223.130.200.107,223.130.195.200,223.130.195.95,223.130.200.104를 찾고 이 IP를 웹 서버로 요청 전달해서 클라이언트와 통신할 수 있도록 함)

참고
https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/

< 도메인의 구조 >

(서브도메인.)(서브도메인.)도메인이름.최상위도메인.

[ ⓒ https://www.beusable.net/blog/?p=4507 ]

[ ⓒ https://www.beusable.net/blog/?p=4507 ]

• 최상위 도메인
  • 국가별 최상위 도메인(ccTLD)와 일반 최상위 도메인(gTLD) 두 유형이 있음
  • 국가 최상위 도메인은 국가 코드를 사용(.kr , .jp , .cn)
  • 일반 최상위 도메인은 다양한 주제나 목적을 나타내는 문자열을 사용(.com , .net , .edu)
  • 최근 최상위 도메인(new gTLD)도 추가(.blog , .app , .shop 등)

< HTTP 기초 >

< HTTP Messages >

HTTP = HyperText Transfer Protocol, HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜
** Application Layer = 최종 사용자 응용 프로그렘에 네트워크 서비스를 제공하고 네트워크에 엑세스 할 수 있도록 함

< HTTP messages >

클라이언트와 서버 사이에서 데이터가 교환되는 방식(요청, 응답)

몇 줄의 텍스트 정보로 구성, 직접 작성할 필요 X, 구성파일 API 기타인터페이스에서 자동으로 완성함.

< 요청(Requests) >

클라이언트가 서버에 보내는 메시지

start line
Start line 의 세가지 요소

1. 수행할 작업(GET, PUT, POST 등), 방식(HEAD, OPTIONS)을 설명하는 HTTP method를 나타냄.
   ex) GET method = 리소스를 받음, POST method = 데이터를 서버로 전송

2. 요청 대상(URL ro URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성. 형식은 HTTP method 마다 다름.

• Origin 형식 : URI Path(슬래시 '/')로 시작하는 경로, URI 경로만을 명시하기 때문에 서버 내에서 상대 경로를 이용하여 리소스를 찾는 경우에 사용

<HTTP Method> <URI Path> HTTP/<HTTP Version>

ex) GET /background.png HTTP/1.1

• Absolute 형식 : 스킴(scheme), 호스트(host), 포트(port), 경로(path)를 모두 포함하는 URI, 요청하는 리소스의 완전한 경로를 명시하기 때문에, 다른 서버로부터 리소스를 가져와야 하는 경우에 사용

<HTTP Method> <Absolute URI> HTTP/<HTTP Version>

ex) GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

• Authority 형식 : 스킴(scheme)을 제외한 호스트(host)와 포트(port) 정보만을 가지는 URI

  <HTTP Method> <Authority> HTTP/<HTTP Version>

  ex) CONNECT developer.mozilla.org:80 HTTP/1.1
  

• Asterisk 형식 : 모든 리소스에 대한 요청을 나타내는 URI

  <HTTP Method> * HTTP/<HTTP Version>

  ex) OPTIONS * HTTP/1.1
  

일반적으로 사용하는 형식은 Origin 형식과 Absolute 형식.

3. HTTP 전에 따라 HTTP message의 구조가 달라짐. 해서 start line에 HTTP 버전을 함께 입력.

< headers >

요청의 Headers는 기본 구조를 따름.
헤더 이름(대소문자 구분 없는 문자열), 콜론(:) 값을 입력, 값은 헤더에 따라 다름.

1. General headers
모든 종류의 HTTP 요청과 응답에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련 없음.

• Cache-Control: 캐시 제어 정보
• Connection: 클라이언트와 서버 간의 연결 유지 정보
• Date: 요청을 생성한 시간
• Pragma: 이전 버전과의 호환성을 위한 정보
• Trailer: 메시지 바디 이후에 추가적인 헤더가 있다는 것을 알려주는 정보
• Transfer-Encoding: 메시지 바디의 전송 방식
• Upgrade: 다른 프로토콜로 업그레이드 하기 위한 정보
• Via: 프록시 서버와 클라이언트 사이의 경로 정보
• Warning: 클라이언트에게 경고 정보를 전달

2. Request headers
클라이언트가 서버에게 전달하는 요청과 관련된 헤더

• Accept: 클라이언트가 원하는 리소스 타입 정보
• Accept-Charset: 클라이언트가 원하는 문자 인코딩 정보
• Accept-Encoding: 클라이언트가 원하는 데이터 압축 방식 정보
• Authorization: 클라이언트의 인증 정보
• Expect: 서버로 보내는 요청에 대한 기대값
• From: 클라이언트의 이메일 주소 정보
• Host: 요청을 받을 호스트 이름
• If-Match: 캐시된 리소스와 일치하는지 확인하기 위한 정보
• If-Modified-Since: 마지막으로 수정된 시간과 일치하는지 확인하기 위한 정보
• If-None-Match: 캐시된 리소스와 일치하지 않는지 확인하기 위한 정보
• If-Range: 범위 리소스 요청을 할 때 사용되는 정보
• If-Unmodified-Since: 마지막으로 수정된 시간과 일치하지 않는지 확인하기 위한 정보
• Max-Forwards: 메시지를 전송하기 위해 허용된 최대 전달 횟수
• Proxy-Authorization: 프록시 서버의 인증 정보
• Range: 리소스의 일부분을 요청하기 위한 정보
• Referer: 이전 웹 페이지 주소 정보
• TE: 전송 인코딩 방식 정보
• User-Agent: 사용자 에이전트 정보

3. Representation headers
요청하는 리소스의 표현에 대한 정보를 제공

• Accept : 클라이언트가 요청하는 리소스 표현의 유형을 지정, 서버는 이 헤더를 사용하여 클라이언트가 요청한 표현을 지원하는지 여부를 결정할 수 있음.
• Accept-Encoding : 클라이언트가 요청하는 리소스의 표현에 대한 압축 방식을 지정함. gzip, deflate 등
• Accept-Language : 클라이언트가 요청하는 리소스의 언어를 지정함.
• Content-Type : 클라이언트가 요청 본문에 포함된 데이터의 형식을 정의. HTML, JSON, XML 등이 있음.
• Content-Encoding : 클라이언트가 요청 본문에 사용된 데이터의 압축 방식을 정의. gzip, deflate 등이 있음.
  
  

< body >

요청의 본문은 HTTP messages 구조의 마지막에 위치. 모든 요청에 body가 필요하지는 않음.

• Single-resource bodies(단일-리소스 본문)
  하나의 리소스를 나타내는 데이터를 담고 있음
• Multiple-resource bodies(다중-리소스 본문)
  하나 이상의 리소스를 포함하는 데이터를 담고 있음
  

HTTP 요청 본문의 유형은 Content-Type 헤더에 의해 지정, Single-resource bodies의 경우 Content-Type 헤더는 해당 리소스의 미디어 타입을, Multiple-resource bodies의 경우, Content-Type 헤더는 "multipart/form-data"와 같은 멀티파트 유형을 지정.

< 응답(Responses) >

Status line
응답의 첫 줄
1. 현재 프로토콜의 버전(HTTP/1.1)
2. 상태 코드 - 요청의 결과를 나타냅니다. (200, 302, 404 등)
3. 상태 텍스트 - 상태 코드에 대한 설명

(HTTP버전) (상태 코드) (상태 코드 설명)

Headers
응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조.
1.General headers
메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련 없음.
2.Request headers
fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더. User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화.Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있음.

• Cache-Control: 응답이 캐싱될 수 있는지 여부와 관련된 정보
• Content-Encoding: 응답 본문에 사용된 인코딩 방식에 대한 정보
• Content-Length: 응답 본문의 길이를 나타내는 정보
• Content-Type: 응답 본문의 미디어 타입을 나타내는 정보
• Date: 응답이 생성된 날짜와 시간을 나타내는 정보
• Expires: 응답이 만료되는 시간을 나타내는 정보
• Server: 서버 소프트웨어의 이름과 버전 정보
• Set-Cookie: 클라이언트 측에서 쿠키를 저장하기 위한 정보
• Location: 응답이 리다이렉트될 위치를 나타내는 정보

  (헤더 이름): (해당 헤더 값)

3. Representation headers
리소스 표현에 대한 정보를 제공

• Content-Type : HTTP 응답 메시지의 본문에 포함된 데이터의 형식을 정의. HTML, JSON, XML 등
• Content-Encoding : HTTP 응답 메시지의 본문에 사용된 데이터의 압축 방식을 정의. gzip, deflate 등
• Content-Language : HTTP 응답 메시지의 본문에 사용된 언어를 정의
• Content-Disposition : HTTP 응답 메시지의 본문에 포함된 파일의 이름과 같은 부가적인 정보를 제공
• Content-Length : HTTP 응답 메시지의 본문의 길이를 바이트 단위로 제공
  
  

body
응답의 본문은 HTTP Messages 구조의 마지막에 위치. 모든 응답에 body가 필요하지 않음. 201, 204와 같은 상태코드를 가지는 응답에는 본문 필요하지 않음.

• Single-resource bodies
  길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의
  길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있습
• Multiple-resource bodies
  서로 다른 정보를 담고 있는 body

Statelss
상태를 가지지 않는다는 뜻. HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않음.

< 두 번째 발표 >

• HTTP의 메소드와 CRUD(create/read/update/delete)를 적절하게 짝짓고, POST와 PUT의 차이점을 설명하세요.

GET: Read / POST: Create / PUT: Update / DELETE: Delete

GET은 서버로부터 리소스를 읽어올 때,
POST는 새로운 리소스를 생성할 때,
PUT은 기존 리소스를 갱신할 때,
DELETE는 리소스를 삭제할 때 사용됩니다. 이렇게 HTTP의 메소드를 CRUD에 매칭시키면, 웹 어플리케이션에서 CRUD 기능을 구현하기 위해 HTTP 메소드를 사용할 수 있습니다.

POST는 요청 본문의 데이터를 새로운 리소스로 생성합니다. 이때, 서버에서는 생성된 리소스의 위치를 클라이언트에게 전달합니다.
PUT은 요청 본문의 데이터를 기존 리소스로 갱신합니다. 이때, 클라이언트가 갱신할 리소스의 위치를 명시해야 합니다. 만약, 명시된 위치에 리소스가 존재하지 않는다면, 서버는 새로운 리소스를 생성합니다.
즉, POST는 새로운 리소스를 생성하고, 서버에서 생성된 리소스의 위치를 반환하는 반면, PUT은 기존 리소스를 갱신하고, 클라이언트가 갱신할 리소스의 위치를 명시해야 한다는 차이점이 있습니다.

• HTTP 응답 코드의 200, 300, 400, 500번대의 특징과 차이점을 설명하세요.

200번대 (Successful): 요청이 성공적으로 처리되었음을 나타내는 응답 코드입니다. 클라이언트가 요청한 작업이 성공적으로 수행되었다는 의미입니다. 예를 들어, 200 OK는 가장 일반적인 200번대 응답 코드입니다.

300번대 (Redirection): 요청한 리소스의 위치가 변경되었거나 다른 대체 요청이 가능한 경우에 사용되는 응답 코드입니다. 이 경우 클라이언트는 새로운 위치로 리디렉션될 수 있습니다. 일반적으로 사용되는 응답 코드로는 301 Moved Permanently, 302 Found, 304 Not Modified 등이 있습니다.

400번대 (Client Error): 클라이언트 측에서 발생한 오류에 대한 응답 코드입니다. 이러한 오류는 클라이언트의 잘못된 요청에 의해 발생합니다. 서버가 클라이언트의 요청을 이해하지 못하는 경우, 존재하지 않는 리소스에 대한 요청 등이 이에 해당합니다. 일반적으로 사용되는 응답 코드로는 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found 등이 있습니다.

500번대 (Server Error): 서버 측에서 발생한 오류에 대한 응답 코드입니다. 이러한 오류는 서버 측의 장애나 오류에 의해 발생합니다. 서버가 클라이언트의 요청을 처리할 수 없는 경우, 서버 측의 장애가 발생한 경우 등이 이에 해당합니다. 일반적으로 사용되는 응답 코드로는 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable 등이 있습니다.

따라서, HTTP 응답 코드는 클라이언트와 서버 간의 통신에서 발생하는 다양한 문제에 대한 응답을 제공합니다. 이를 통해 클라이언트는 요청 결과를 이해하고, 적절한 조치를 취할 수 있으며, 서버는 이러한 응답 코드를 기반으로 문제를 해결하고, 서비스 품질을 개선할 수 있습니다.

오늘도 어떻게 하다보니 다 했음. gpt는 내 시간을 너무 아껴줌.
평소랑 똑같이 또 했다면 주어진 시간동안 구글링을 하고 자료를 모아서 정리 했다면 3시간 안에 못했을 듯...
내가 실력이 없으니까 자료를 가져와도 맞는건가 틀린건가 계속 의문임. 다르게 설명하는 부분들이 있음...
오늘은 자료를 세번은 더 읽고 내용 숙지를 못하더라도 간단하게 기억날 수 있도록 해야겠다.