Port

  • 가상의 논리적 통신 연결단
  • 번호로 구분

항구번호를 통해서 여러갈래의 길이 있어서 다른 목적에 따라 사용

접합부분, 신호가 들어가는 부분을 포트라고 한다.

0~65535

0 ~ 1024 : well-known port - 가상의 통로

80번 포트 : HTTP 웹페이지 전송

1
2
www.daum.net:80
www.daum.net호스트를 찾아서 80번 구멍으로 들어가는데
1
2
www.daum.net:800
이 경우 잘못된 곳에 정착하는 경우 열리지 않는다.응답을 하지 않고 800포트는 열려있지않기떄문에

443번 포트는 http통신을 위한 것

보안용은 안쓰나?

http://www.naver.com:80 // 여기로는 들어가짐

https://www.naver.com:80 // 여기로는 안들어가지는데 그것은 네이버에서 https서비스는 하지않다는것.

해킹시 포트를 타고 들어와서 해킹을 하기도 함

그래서 방화벽을 세우거나 함

예) 인천공항에 비행기가 출항하려고 떠다니는것 처럼

수강신청시 몇만명이 80포트로 들어가려고 하다보니 대기하다가 들어가고 그런것인데

미리 다른 포트를 열어놓고 수강신청을 쉽게 하는것

DNS

OSI 계층

​ [ 7 layers of the OSI Model ]

해당 경로를 통해서 데이터를 패킷에 묶여서 나옴

실제로 케이블들이 물리적으로 이어져있음 해저에 박혀있음

그래서 로밍서비스시 비싼 이유가 고속도로에 돈받는것처럼 그런거

사실 그냥 인터넷 더 빠르게 사용할수 있는데 통신사에서 대로폭 제한을 해서 돈낸만큼만 대로폭제한을 해서 그만큼만 사용하게 된다.

전기의 저항은 가다가 점점 줄어듬 열을 받고 해서

1-10 을 주면 7 6 으로 줄어들게 되서 이게 처음에 10이였는지 9이였는지 모르기에

0 -1 으로 해서 1로 시작해서 0.6이 되도 1인줄알게 컴퓨터는 0과 1을 사용한다.

증폭기를 중간중간에 사용하는것도 그런것 약해지니까 중간중간에 증폭기를 세움

대부분 전선은 구리를 사용한다 금은 너무 비싸니까.

HTTP

  • 월드 와이드 웹에서 정보를 주고 받을 수 있도록 고안한 프로토콜
  • Well-known port: 80

HTTP의 역사

  • HTTP/0.9 : 1991~
  • HTTP/1.0 : 1996
  • HTTP/1.1: 1997
  • HTTP/2 : 2015

HTTP Request / Response

  • Request: 클라이언트에서 웹 서버로 요청
  • Response: 웹 서버에서 클라이언트로 응답

www를 사용시 웹문서를 요청한다는 것

HTTP Header / Body

  • Header
    • 웹서버와 클라이언트사이에서 실질적인 데이터 외에 추가적인 정보를 교환할 수 있도록 선두에 삽입되는 정보
  • Body
    • 웹 서버와 클라이언트 사이에서 전송할 실질적인 데이터

헤더가 없으면 컴퓨터는 어떤 데이터가 들어왔는지 알수 없다.

사이트: https://docs.trafficserver.apache.org/en/latest/developer-guide/plugins/http-headers/index.en.html

Content-length는 바디에 들어올 정보의 길이가 몇인지도 알려줌

Mime-type : text인지 xml, json인지가 들어가있음

HTTP Request Methods

  • 웹 서버에 요구하는 작업의 종류에 따라 요청방법(Request Method)을 구분
  • GET, POST, PUT, DELETE, HEAD, TRACE, OPTIONS, CONNECT, PATCH등

GET

  • 요청 URL에 해당하는 자료의 전송을 요청
  • Request Body( X ) | 정보를 가져올시 body가 아닌 헤더에서 정보요청을 함 / 처음에는 바디는 필요없어도 된다.
  • Response Body( O )

POST

  • 서버가 처리할 자료를 전송
  • Request Body( O ) | 바디에 정보를 실어서 요청
  • Response Body ( O )

CRUD

create, read, update, delete

POST, GET, PUT, DELETE

1) 사용자 정보 만들고

2) 사용자 정보를 요청받아 읽고 정보조회

3) 사용자 정보를 수정하고

4) 사용자 정보를 삭제
Create POST
Read GET
Update PUT
Delete DELETE

DELETE

  • 해당 URI의 자료를 삭제
  • Request Body( X )
  • Response Body( O )

HTTP Request Methods

Request Body Request Body
GET X O
POST O O
PUT O O
DELETE X O

Status

서버의 상태를 말해줌

HTTP Response Status Code

  • 1xx : 정보교환 / 조건부 응답
  • 2xx: 성공
  • 3xx: 리다이렉션
  • 4xx: 요청 오류
  • 5xx: 서버 오류

예) 404에러 페이지 정보를 찾지 못했을때

https://developers.naver.com/main/

  • 서버에 필요한 정보를 클라이언트에 임시/영구적으로 저장하기 위해 저장

  • 사용자에 대한 지속적인 상태감시 및 상태참조의 목적

  • 여러 페이지를 옮겨 다닐 때에도 통용될 정보에 주로 이용

    예) 사용자 이름, 아이디, 장바구니, 최근 본 상품 등등

cookie

구글은 사용자의 쿠키 번호를 갖고 쿠키에 검색을 뭘하는지 뭘하는지를 정보를 분석

  • Read Cookie

    Var cookies = document.cookie

  • Write Cookie

    • Document.cookie = “user_name=Jo; user_id=yagom”

Cookie의 종류

  • 영구적 쿠키 : 하드디스크에 저장
    • 디스크에 저장 - 만료일 후에 삭제
    • 만료일을 집어늠
  • 세션 쿠키 : 메모리에만 저장: 요즘은 이거 씀
    • 주로 세션 정보를 보관하기 위해 사용
    • 메모리에 저장 - 브라우저 종료후 사라짐
  • 악성코드 및 멀웨어에 의해 읽힐 수 있어 보안에 취약
  • 보안에 신경쓸 필요가 없으며 간단한 데이터를 통신간에 유지하기 위해 사용

참고: http://www.jynote.net/263

Session

  • 웹 서버가 HTTP 요청을 한 클라이언트를 식별하기 위해 사용
  • 클라이언트의 최초 요청에 세션 쿠키로 임의의 난수를 생성
  • 클라이언트의 이후 요청에 세션ID를 헤더에 담아 보내면 서버에서는 이를 통해 클라이언트를 식별

예) 아이피에 해당하는 세션키를 줬다가 다른곳에서 가서 인터넷을 했을시 아이피가 달라져서 세션이 만료됬다고 하는것과 같은것

쿠키는 서버에 부담이 덜 되고

세션은 서버에 부담이 더 되고 계속 아이피에 해당하는 세션키를 주고 체크해야되지만 쿠키에 비해선 안전

세션쿠키가 세션에 사용되는것

세션 쿠키에 세션키만 갖고 있으면 되니까 쿠키보다 가볍고

Cache

임시저장소

  • 통상적 의미: 데이터나 값을 미리 복사해 놓은 임시 장소
  • 웹 서버 - 클라이언트 모델에서의 캐싱
    • 서버-클라이언트 간 요청에 대한 응답을 저장해 두는 것
    • 서버의 부하와 접속 속도 문제 완화
    • 새로운 데이터의 갱신 문제

네이버에 자주들어가면 해당 사이트를 캐시에 저장해서 다음에 다시 들어가려고 했을때 요청의 응답이 없어도 캐시를 이용해서 보여지게 됨

캐시파일도 만료일을 알려주기도 함 그래서 갱신된게 있는지 서버에 요청해서 업데이트되기도 함

HTTP/2

  • 현재 많이 사용되고 있는 HTTP/1.1을 개선하기 위한 차기 버전
  • 아직 많이 사용되지 ㅇ낳고 있지만 곧 확장될 예정

Why HTTP/2?

  • 헤더 압출 지원
    • 쿠키의 과다 사용. .
    • HTTP/1.1의 헤더는 너무 크고 복잡
    • 속도 저하의 원인
  • 너무 빈번한 Round-trip
    • 한번의 요청으로 다양한 데이터 응답 가능

보통 한개의 페이지만 해도 스크립트,이미지 ,동영상파일을 받는데 왔다갔다를 많이 하게 되는데

HTTP/2는 한번에 응답해주는것이 기본 컨셉

패킷이란?

네트워크를 통해서 전송되는 단위, 데이터의 묶음

소켓통신

Http는 라운드트립이 되는 식인데 왔다갔다 뭘 부르고자 할때 한번 요청하고 응답을 받는 식인데

채팅에 경우 http는 계속 주고 받고를 해야 되므로 좀 그렇다

수로를 파서 주든지 받든지 가상의 통신의 설로를 만들고

한쪽에서 양쪽에서 계속 실시간으로 싱크를 하고 있는 모습

비용이 많이 듬 계속 감시해야 되는 의무가 있어서 시스템자원들을 소모하게 됨

서버부하되는것도 생각하면 데이터베이스를 잘 짜지않으면 별로임 잘 사용할줄 모르면 별로임

풀링

암호화

  • 해시
  • 대칭키
  • 공개키(비대칭키)

해시 함수

  • 임의의 데이터(암호 등)를 고정된 길이의 데이터로 매핑하여 원래의 입력값과의 관계를 찾기 어렵게 만든것
  • SHA, MD5 등

해시함수로 암호화해서 저장

예) 로그인을 위해 유저가 정보를 적으면 아이디, 이름, 비밀번호

비밀번호를 암호화 해서 데이터베이스에 저장

로그인할때 입력한 비밀번호를 암호화해서 데이터베이스에 있는 암호화된애랑 비교

이것은 0부터 z까지 쳐서 만들면 저 암호화된애들을 집어넣으면 저 암호화된 애들을 찾을수 있게 됨

해커 와 크래커

해커는 막으면서 공격하고

그래커는 구멍을 찾아서 공격하는거

대칭키 암호화

  • 암호와와 복호화에 같은 암호키를 쓰는 알고리즘
  • DES, AES, SEED등

O >> *

  • << O

암호화할 키를 알게 되면 끝이라는 단점이

공개키(비대칭키) 암호화

  • 공개키로 암호화된 데이터를 비밀키를 사용하여 복호화 할 수 있는 암호화 알고리즘
  • RSA등

예) A와 B는 암호화할 키와 복호화할 키를 각각 가지고 있음

잠글떄 쓰는 키를 줘도 풀수는 없음

암호화 할때 쓰는 키

그러나 여는 키는 각자 혼자 갖고 있기떄문에 여는 키만 안털리면 됨

알고리즘이 복잡해서 푸는데 메모리를 많이 차지하게 되고 연산을 위해 cpu도 많이 쓰게 됨

그래서 사람들이 생각한 것이

처음에는 공개키 비대칭키를 사용하여 비밀키를 주고 받은후 나중에 주고 받을때는 대칭키를 사용하기로 함

http SSL같은거에 사용 이게 암호화 방식

공인 인증서가 유사한 컨셉이 그것임