캐싱이란?

- 애플리케이션 처리 속도를 높여주는 이미 가져온 데이터나 계산된 결과값의 복사본을 저장하여 처리 속도를 향상시키고 , 이를 통해 향후 요청을 더 빠르게 처리할 수 있다. 

- 대부분의 프로그램이 동일한 데이터나 명령어에 반복하여 액세스하기 때문에 캐싱은 효율적인 아키텍쳐 패턴

캐싱 적합한 데이터

• 반복적이고 동일한 결과가 나오는 기능의 반환값
• 업데이트가 자주 발생하지 않는 데이터
• 자주 조회되는 데이터
• 입력값과 출력값이 일정한 데이터
• 캐싱된 데이터는 데이터 갱신으로 인해 DB와 불일치가 발생할 수 있다.
  => 그렇기 때문에 데이터 Update가 잦게 일어나거나 데이터 불일치시 비즈니스 로직 상 문제가 발생할 수 있는 기능은 캐싱 대상으로 적합하지 않음

캐싱 타입

• Local Cache
  • 서버마다 캐시를 따로 저장한다.
  • 다른 서버의 캐시를 참조하기 어렵다.
  • 서버 내에서 작동하기 때문에 속도가 빠르다.
  • 로컬 서버 장비의 Resource를 이용한다. (Memory, Disk)
  • 캐시에 저장된 데이터가 변경되는 경우:
    • 해당 서버를 제외한 모든 peer에 변경 사항 전달
    • All-to-All Replication
    • WAS 인스턴스가 늘어나고, 캐시 저장 데이터 크기가 커지면 성능이 저하되는 이유는 이 때문
• Global Cache
  • 여러 서버에서 캐시 서버에 접근하여 참조 할 수 있다.
  • 별도의 캐시 서버를 이용하기 때문에 서버 간 데이터 공유가 쉽다.
  • 네트워크 트래픽을 사용해야 해서 로컬 캐시보다는 느리다.
  • 데이터를 분산하여 저장 할 수 있다.
    • Replication: 두 개의 이상의 DBMS 시스템을 Mater / Slave 로 나눠서 동일한 데이터를 저장하는 방식
    • Sharding: 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법
  • 캐시에 저장된 데이터가 변경되는 경우:
    • 추가적인 작업 필요없음
    • 서비스 확장으로 WAS 인스턴스가 늘어나고, Cache 데이터 크기가 커질 수록 효과적인 이유

캐싱용 인메모리 DB (Redis VS Memacached)

두 기능 모두 NoSQL 형식으로 키-값 형태를 이루어 두 솔루션 모두 캐시 레이어로서 동작 

Memcachedsms In-Memory Key-Value 저장소라 한다면, Redis는 단순한 KEY-VALUE를 저장소에서 더 나아가 일종의 데이터 구조 스토어라고 합니다. 

자바 언어에서는 Memcached는 Xmemcached과 Memcached-java-client를 제공하고

Redis는 Jedis, Lettuce, Redisson을 제공합니다.

주요 특징 비교 

데이터 자료형, 그에 따른 메모리 사용량

Memcached : key와 value가 String 자료형으로 최대 1MB까지 저장 / String으로만 구성되어 Redis 보다 빠르고 
Redis의 Hash로 직렬화, 역직렬화 과정을 거치지 않고 객체를 저장할 수 있어 애플리케이션 개발이 수월해지고 IO 과정이 줄어 들어 효율적

Redis :  5개의 데이터 자료형(String, Hash, List, Set, Sorted set)을 사용하며 키와 값 모두 512MB까지 저장 가능 

구조 , 확장법

Memcached : 멀티 코어 구조로 된 멀티 쓰레드를 지원 / vertical scale up(=수평적 확장) 으로 확장성 얻음

Redis :  싱글 쓰레드 구조 / 슈평, 수직 확장 가능 / 수평적 확장은 노드 그룹(=샤드) 개수 조정 , 수직 확장은 클러스터 크기 증가

Data Eviction 알고리즘(=메모리 여유공간 없을 때 자원 쫓아낼때 사용되는 알고리즘)

Memcached : LRU(Least Recently Used)

Redis : 하기 8가지 정책 중 선택

트랜잭션

Memcached : 원자성은 있지만, 트랜잭션 미제공  / 멀티 쓰레드 구조로 여러 쓰레드가 한번에 동일한 트랜잭션 기능에 접근하게되면 원자성을 보장하게되도, 다른 쓰레드의 값과 겹쳐질 수 있음. 

Redis : 트랜잭션 기능 제공 / WATCH , MULTI , EXEX 등의 명령어 기반 optimistic lock 기반 트랜잭션 지원 

개요

X-Forwarded-For(XFF) 란?
- XFF 는 HTTP Header 중 하나로 HTTP Server 에 요청한 Client 의 IP 를 식별하기 위한 표준

- 웹 서버나 WAS 앞에 L4 같은 Load balancers 나 Proxy server, caching server 등의 장비가 있을 경우,
  웹서버는 Proxy server 이나 장비 IP 에서 접속한 것으로 인식

==> 웹 서버는 실제 클라이언트 IP가 아니라 앞단 Proxy 서버 를 요청한 IP로 인식 / Proxy  장비 IP로 웹 로그 남김

웹 프록시 동작에서의 사용자 IP 변환

1번 과정에서 클라는 웹 서버와 세션을 맺으려하나 실제로는 웹 프록시와 TCP 세션을 맺게 되며

3번 과정에서 웹 서버는 클라이언트와 TCP 세션을 맺으려 하나 웹 프록시와 TCP 세션을 맺게 됨.

==> 지연 바인딩 과정(Delayed Binding)

3번의 과정에서부터 웹 프록시와 웹 서버 간의 동작에서 소스 IP가 웹프록시 IP로 변경되며 

그로 인해 웹 서버는 실제 사용자 IP를 확인하지 못합니다.

IP 변경에 따른 고려사항

사용자 IP가 변경되게 된다면

해당 데이터를 통해 수집되는 로그에서 사용자 IP를 구별할 수 없어 

사용자 IP 기반의 서비스 및 정책들에 제약이 걸려 사용할 수 없게 되기 때문에 클라이언트 IP를 찾을 수 있어야 합니다. 

XFF

HTTP 프록시나 LB를 통해 웹 서버에서 접속하는 클라이언트의 실제 IP주소를 식별하는 표준 헤더로 

문법은 아래와 같습니다. 

X-Forwarded-For: <client>, <proxy1>, <proxy2>

- client : 클라이언트  ip 주소

- proxy1, proxy2 : 하나의 요청이 여러 프록시를 거치면 각 프록시 ip주소들이 차례로 열거 / 가장 오른쪽 ip 주소가 가장 마지막에 거친 프록시 ip 주소

관련 코드 

String ip = request.getHeader("X-Forwarded-For");

if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    ip = request.getHeader("Proxy-Client-IP");
     # WAS(WebLogic)의 webserver 연계 모듈인 weblogic connector 에서 사용되는 헤더
}
if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    ip = request.getHeader("WL-Proxy-Client-IP");
    # WAS(WebLogic)의 webserver 연계 모듈인 weblogic connector 에서 사용되는 헤더
}
if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    ip = request.getHeader("HTTP_CLIENT_IP");
     # PHP . ASP 에서 실제 Clinet IP를 구할때 사용하는 헤더
}
if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    ip = request.getHeader("HTTP_X_FORWARDED_FOR");
    # PHP . ASP 에서 실제 Clinet IP를 구할때 사용하는 헤더
}
if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    ip = request.getRemoteAddr();
}

PHP 사용방식

function getRealClientIp() {
    ...
    if (getenv('HTTP_CLIENT_IP')) {
        ip = getenv('HTTP_CLIENT_IP');
    }
    if(getenv('HTTP_X_FORWARDED_FOR')) {
        ip = getenv('HTTP_X_FORWARDED_FOR');
    }
    ...
}

ASP 사용방식

string ip = Request.ServerVariables["HTTP_X_FORWARDED_FOR"]; 
if(string.IsNullOrEmpty(ipaddr)) {
    ip = Request.ServerVariables["REMOTE_ADDR"];
}

Rest API 설계 검색하다가, HTTP/3가 베타 중(?)이라는 소식에 정리해보는 페이지입니다. 

HTTP/3

HTTP/3 : HTTP(Hypertext Transfer Protocol)의 세번째 메이저 버전으로,
HTTP/1, HTTP/2 와 다르게 UDP 기반의 프로토콜(QUIC(Quick UDP Internet Connection))사용하여 통신하는 프로토콜

TCP(HTTP/1,2) vs UDP

TCP : 신뢰성이 높고 느리며 (느린 이유는 3 way Handshake를 사용하기 때문)

UDP : 신뢰성이 낮고 빠르다

 # 신뢰성 : 전송되는 데이터 패킷들의 순서, 패킷 유실 여부 등을 검사하여 송신 측이 보낸 모든 데이터가 수신 측에 온전하게 전달될 수 있느냐 ? 를 의미한다.

TCP는 클라-서버간의 통신에서 신뢰성을 가지기 위해 노력하지만 결국, 레이턴시가 발생할 수 밖에 없다.(TCP 표준)

레이턴시를 줄이기 위해서는 TCP 표준에서 벗어나는 부분을 조작해서 회선 대역폭을 늘린다 하여도 , 

전송해야하는 데이터의 크기도 점점 커지고 빛의 속도보다 빠르게 전송은 불가능하여 결국에는 한계에 도달하게 된다.

QUIC

TCP 의 레이턴시 한계를 극복하고자 구글이 개발한 UDP 기반의 프로토콜로 

TCP 핸드쉐이크 과정을 최적화하는 것에 초점을 두었다. 

UDP 는 데이터그램 방식의 프로토콜로 

각각의 패킷 간의 순서가 존재하지 않는 독립적인 패킷을 사용하며, 

패킷의 목적지만 정해져있다면 중간 경로는 무시하기 때문에 종단 간의 연결 설정이 필요없다. (= 핸드쉐이크가 없다)

그래서 왜 QUIC은 UDP를 선택했을까?

물론, TCP를 사용하다가 UDP로 바로 갈아탄다고 해도, 모든 이슈가 해결되지는 않지만 

UDP의 커스텀 기능 이용을 통한다면 기존 TCP가 가지고 있는 기능을 모두 구현할 수 있다.

데이터 전송 자체에만 초점이 맞추어 있기 때문에 출발지, 도착지, 패킷 길이, 체크섬(옵션) 만 존재(위 그림)

즉, 어떻게 개발자가 구현하냐에 따라
TCP와 비슷한 수준의 기능을 가질 수 있으며 핸드쉐이크를 사용하지 않을 수 있다는 의미와 같다. 

HTTP/3가 UDP를 사용하여, 기존 프로토콜보다 개선된 점 

1. 연결 설정 시 레이턴시 감소

클라이언트 보낸 요청 -> 서버 처리 -> 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라 하는데, 

위에서 설명한 내용과 같이 QUIC은 첫 연결 설정에서 1RTT만 소요된다. (아래 그림 참조)

즉, 클라이언트가 서버에 신호를 주고 서버에서 응답만 받으면 바로 본 통신이 가능하다는 말과 같다. 

첫번째 핸드쉐이크를 거칠 때
연결 설정에 필요한 정보(+(초키화 키(initial Key) 통해 통신 암호화)와 함께 데이터도 함께 보내기 때문에 가능한 일이다.
(TCP+TLS는 데이터 발송 전 신뢰성있는 연결, 암호화에 필요한 모든 정보를 교환하고 유효성 검사 후 데이터 교환)

2. 패킷 손실 감지에 걸리는 시간 단축

패킷 전송 -> 타임 아웃 -> 패킷 재전송 -> ACK 받음 의 통신을 진행하는데

이때 ACK가 어떤 패킷에서 온건지 확인하기 위해 QUIC는 헤더에 별도의 패킷 번호 공간을 부여하였다. 

해당 번호는 패킷의 전송 순서 자체만을 의미하고 매 전송마다 모노토믹하게 패킷 번호가 증가하기 때문에 패킷의 전송 순서를 명확하게 파악할 수 있다.

3. 멀티플렉싱 지원

여러 개의 스트림을 사용하여 그 중 특정 스트림의 패킷이 손실되었다고 하여도 해당 스트림에만 영향을 미치고 타 스트림에 영향을 주지않아 TCP의 단점인 HOLB(Head of Line Blocking)을 방지할 수 있다. (=HTTP/2와 동일)

4. 클라이언트 IP 변동되어도 연결 유지 

Connection ID를 사용하여 서버와 연결을 생성하는데, 

이때 Connection ID는 랜덤한 값일 뿐 클라이언트 IP와 전혀 무관하기 때문에 클라이언트 IP가 변경되어도 기존 연결을 지속적으로 유지할 수 있다. (=새롭게 연결을 생성할때 핸드쉐이크 과정을 생략할 수 있다는 말과 같다)

기존의 HTTP , TCP 방식에서 벗어날 용도로 쓸 수 있지만

grpc와 비교할 필요가 있을 것 같다 (비슷한 용도지 않나?)

latency(지연 속도)

패킷을 전송하는 곳에서부터 전달받는 곳까지 이동하는 데 걸리는 시간

아래 4가지 지연을 합친 것이 레이턴시 

- 전파 지연(propagation delay / 서버-클라이언트 간 총 레이턴시는 총 이동거리 대비 신호가 이동하는 속도)

- 전송 지연(transmission delay / 패킷의 모든 비트를 내보내는 데 필요한 시간)

- 프로세싱 지연(procession delay / 패킷 헤더 처리 시간)

- 큐잉 지연(queuing delay / 패킷이 처리될 때까지 버퍼 안에서 대기하는 시간) 

 latency는 두 네트워크의 거리가 멀 때 높아짐

bandwidth(대역폭)

물리적으로(혹은 논리적으로) 처리할 수 있는 통신 경로의 최대 데이터 양 => 네트워크통해 전송되는 처리량 

- 초당 비트 수(bps)

- 사용자가 많이 접속된 상태에서는 대역폭이 상대적으로 줄어든다.

- 이상적인 전송량 

throughput(처리량, 출력)

지정된 시간 내에 전송된, 혹은 처리된 전체의 유효한 정보량(=처리량)

- 실제로 전달된 전송량 

더 높은 대역폭과 더 낮은 지연 시간 달성하려면(delivering)?

- 대역폭 : 경제적 여건이 허용되는 한 섬유 링크를 추가한다

- 지연 시간 : 빛의 속도보다 빠르게 전달할 수 없으므로 굴절률을 낮추고 더 빠른 라우터를 개발해도 최대 30% 기대/ 전송하는 곳과 받는 곳 사이의 거리를 줄임으로써 속도를 단축시킬 수 있지만 사회적, 소요되는 비용 등을 생각해보면 .. 

따라서 ,애플리케이션의 성능을 향상시키기 위해서는,
가능한 대역폭과 속도 내에서 프로토콜과 네트워킹 코드를 설계하고 최적화하는 것이 최선.

로드밸런싱?

컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은
컴퓨터 자원들에게 작업을 나누는 것을 의미

로드밸런서(=스위치) 종류

• 운영체제 로드밸런서
  - 물리적 프로세서 간에 작업을 스케줄링
• 네트워크 로드밸런서
  - 사용 가능한 백엔드에서 네트워크 작업을 스케줄링

스위치의 분류

L2 : OSI 레이어 2에 속하는 MAC 어드레스를 참조하여 스위칭하는 장비

L3 : OSI 레이어 3에 속하는 IP주소를 참조하여 스위칭하는 장비

L4 : OSI 레이어 3~4에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비
L7 : OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭함

로드밸런서 주요 기술

• NAT(Network Address Translation)
  - 사설 ip주소를 공인 IP주소로 변경, 주소변경의 역할
• DSR(Dynamic Source Routing protocol)
  - 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념
• Tunneling
  - 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념
  - 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제

로드밸런싱 Failover

로드밸런서 장애 방지를 위해 이중화 구성 필요

1. vip로 접속을하고 active된 로드벨런서로 연결
2. 장애가 났을경우 standby중인 로드밸런서로 연결
3. 이중화된 로드밸런서에서 Health Check
4. 장애로 여분 로드밸런서가 동작 할 경우 이를 통해 서버 접근

네트워크 로드밸런서 종류

가장 많이 쓰이는 로드밸런서는 아래 2가지

• L4(Transport Layer)
  - Transport Layer(IP+Port) Load Balancing
  - 예시: IP+Port > 213.12.32.123:80, 213.12.32.123:1024
  - TCP/UDP 포트 정보를 분석해 해당 패킷이
    현재 사용하는 서비스 종류(HTTP, FTP, 텔넷, SMTP, POP3, SSL등)별로 PACKET을 처리
  - 장점 : Port기반 스위칭 지원, VIP를 이용하여 여러대를 한대로 묶어 부하분산
  - 주로 Round Robin 방식 사용
• L7(Application Layer)
  - Application Layer(사용자 Request) Load Balancing
  - 예시 : IP+Port+패킷 내용 >
  213.12.32.123:80, 213.12.32.123:1024 + GET/ img/aaa.jpg
  - HTTP, FTP, SMTP Protocol 등의 콘텐츠를 인지하여 원하는 포트로 전달하는 스위치 (콘텐츠 기반 스위칭)
  - 쿠키 기반의 연결 지속성 (클라이언트 IP가 Public IP로 치환되어 전송 -> X-Forwarded-For에 client ip기록)

L4 

동작 방식

1. Clinet(=브라우저) 에서 주소(ex. 111.co.kr) 입력 -> PC Local DNS 서버로 DNS Query -> DNS 서버에서 111.co.kr 관리하는 Authoritative DNS 의 DNS Query, L4의 VIP주소 획득
2. Local DNS가 획득한 VIP 주소를 전송
3. 획득한 DNS를 기반으로 L4 VIP로 http 요청
4. L/B장비는 최적의 서비스 서버를 내부 알고리즘(라운드로빈 등)을 통하여 선별, 요청 전송 ->
   서버 작업 결과를 L/B장비 전송
5. 전달받은 http결과를 L/B장비를 통해 Client에 전송함으로 요청 처리 완료

L4 이슈 

프록시 서버 사용 시 이슈가 발생하며

예를 들면 회사 -> 외부 나갈 시 각 PC의 IP가 아니라 프록시 서버 IP를 갖고 나가기에

여러 사람이 timeout 시간 내에 접속할 경우, 지속적으로 한 서버에만 로드 집중 (외부에서 보면 동일한 사람으로 보임)

=> 해결책 : SSL 이나 타 보안 모듈 이용하여 인증된 특정 사용자에 대해쿠키, DB에 기록 후 해당 사용자에 대해서만 세션 유지 하도록 한다 (단점은 퍼포먼스 저하 및 기타 코스트가 발생)

단점을 해결하기 위해 하기의 L7을 사용. 

L7

동작 방식

aaa.co.kr 접속 -> 서비스 종류(포트별 구분 HTTP, FTP 등) 별로 분기하여 처리 

L4 vs L7

1. 구조 차이 
   • 공통점 : 스위치로 들어온 Packet을 적절한 목적지(주로 네트워크 장비나 클라이언트, 때로는 불필요한 Packet을 Drop시키기도 함)로 전송해줌. 기본적인 기능과 역할은 동일하나 Packet을 분석해 성격과 중요도를 분류하는 Intelligence가 달라서 "적절한 목적지"를 찾아내 해당 Packet을 처리해 주는 능력에 차이가 발생함.
     
     
   • 차이점 
     • L4 : TCP/UDP 포트 정보 분석 통해 해당 패킷 사용하는 서비스 종류에 따라 패킷 처리 
     • L7 : 트래픽 컨텐츠 패턴 분석해 패킷 처리 
2. 기능적 차이 
   * 보다 높은 수준의 Intelligence를 갖춘 스위치일수록 더 정교한 패킷의 부하분산(Load Ballancing)및 Qos기능 가능
   • L7스위치는 다음과 같은 기능을 통해 네트워크 시스템의 보안성 강화가 가능
     1) Dos/SYN Attack에 대한 방어
     2) CodeRed/Nimda등 바이러스 감염 패킷의 필터링
     3) 네트워크 자원의 독점 방지를 통한 네트워크 시스템의 보안성 강화가 가능
     
     

개발 진행 중 권한 업무를 위해 필요한 업무 지식이 있어 정리합니다. 

LDAP ( Lightweight Directory Access Protocol ) ?

• 정의 : 네트워크 상에서 어떠한 정보(전화번호, 주소, 조직, 파일, 프린터등 하드웨어 위치, 계정 등등)를 쉽게 찾아 볼 수 있게 하는 소프트웨어 프로토콜
  
  
• 계층구조를 갖는 데이터를 네트워크를 통해서 교환할 수 있게 하는 프로토콜로,
  이는 인증을 위한 중앙 저장소의 프로토콜로 사용하는 것
  
  
• 프로토콜은 표준이기에,
  각 어플리케이션 벤더들이 이를 기반으로 인증 기능(이러한 서비스를 디렉토리 서비스) 구현 
  
• 모든 데이터 항목은 LDAP 서버에 의해 색인화됨 
  
  
• 저장된 정보가 매우 드물게 업데이트되고, 빠른 검색이 필수라면 LDAP 서버가 이상적
  
  
• LDAP 인증 아키텍처 / 구성요소 
  • 인증 옵션
    1. Simple 옵션
       • Anonymous 인증 : client에게 anonymous 상태로 LDAP 에게 전달함
       • Unauthenticated 인증 : 오직 logging 목적으로 client에 대한 접근권한을 주지 않음.
       • Name/Password 인증 : 자격을 기반으로 서버에 대한 접근 권한을 부여함.  (간단하지만, 기밀성 보호가 없는 인증에는 적합하지 않음..)
    2. SASL(Simple Authentication and Security Layer) 옵션
       • LDAP 서버를 다른 인증 매커니즘 (ex) kerberos)와 연계 

AD ( Active Directory ) ?

• 정의 : 다양한 표준화 프로토콜을 사용하여 다양한 네트워크 관련 서비스 제공하는 DB 기반 시스템
  모든 정보와 구성 정보를 중앙 데이터베이스에 저장하여 사용하며, 관리자가 AD를 통해 정책 할당, SW 배포 및 업데이트 쉽게 수행
  
  
• 사용자가 네트워크 리소스에 액세스 할 수 있도록 SSO(Single Sign On) 제공
• 서버 간의 디렉터리에 대한 업데이트 쉽게 동기화
• 확장성이 뛰어나기에 소규모 네트워크 ~ 대규모 네트워크 (수천명) 단위에서도 사용되며, 회사에서 응용 프로그ㅡ램에 표준화 된 액세스를 제공하는데도 사용 
• AD는 LDAP(디렉터리 서비스 위한 프로토콜)을 사용할 수 있고, Keroberos(티켓 기반 매커니즘 통해 인증 수행) 을 사용하여 인증할 수 있음.
  
  
  • kerberos 동작 방식 

  • 

    
    
    1. 사용자가 ID/PW 또는 공개키로 로그인을 시도
    2. 클라이언트는 유저 아이디를 인증서버(AS)로 전송
    3. 인증서버(AS)는 중앙저장소(LDAP)에 유저 아이디 확인 후 존재할 경우 다음을 반환
       • 클라이언트 PW 기반으로 암호화한 티켓 발급 서버(TGS)의 세션키
       • 클라이언트 ID, 주소, 유효기간, TGS 세션키를 TGS 비밀키로 암호화한 티켓발급용 티켓(TGT : Ticket Granting Ticket)
    4. 클라이언트는 다음 두 가지를 티켓 발급 서버(TGS)에게 전송
       • 클라이언트 ID, Timestamp를 TGS 세션키로 암호화한 인증자
       • 티켓 발급용 티켓(TGT) (클라이언트는 TGS 비밀키를 모르므로 복호화 및 조작 불가) 
    5. 티켓 발급 서버(TGS)는 인증자(TGS 세션키로 복호화)와 TGT(TGS 비밀키로 복호화)를 복호화 하여 Client ID가 일치할 경우 아래 두 메시지를 반환
       • 티켓발급서버(TGS) 세션키로 암호한 SS 세션키
       • 클라이언트 ID, 주소, 유효기간, SS세션키를 SS 비밀키로 암호화한 티켓
    6. 클라이언트는 다음 두 메시지를 서비스 서버(SS)로 전달
       • 클라이언트 ID, Timestamp를 SS 세션키로 암호화한 인증자
       • 티켓
    7. 서비스 서버(SS)는 Ticket, 인증자를 복호화하여 Client ID가 일치 할 경우 다음 메시지를 반환
       • Timestamp를 SS세션키로 암호화하여 반환
    8. 클라이언트는 전달받은 timestamp와 자신이 인증자에 담아보냈던 timestamp의 값을 확인하여 일치하는 경우 실제 작업을 시작
       
       동작 방식 참고 : https://ldap.or.kr/?p=1291

아마도~ ad로 개발하지 않을까..

TCP / IP 4계층

TCP/IP : 인터넷과 관련된 다양한 프로토콜의 집합 → OSI 7계층을 4계층으로 단순화한 모델의 의미

TCP/ IP 계층 설명

계층을 4단계로 나눈 이유는 각 계층마다 독립성을 보장하기 위함으로, 

문제가 발생했을 때 해당 계층만 확인하면 된다는 말과 같습니다. 

각 계층의 역할은 다음과 같습니다. 

1. 링크 계층
   • 인터넷 계층에서 형성된 패킷을 전기신호 또는 광신호로 바꾸어 전달
2. 인터넷 계층
   • IP( Internet Protocol ) 프로토콜은 인터넷 계층에 존재하며, 링크 계층을 통해 물리적으로 연결된 호스트 사이에서 패킷의 전달 경로를 결정
   • 즉, IP 프로토콜은 라우팅 방법을 정의하는 것인데, 상위 계층인 전송 계층이 데이터 전달의 신뢰성을 책임진다는 가정하에 어떤 경로로 패킷을 전송할 것인가에 초점
3. 전송 계층
   • 인터넷 계층에서 결정한 목적지까지 실제 데이터를 신뢰성 있게 전송하는 역할
   • TCP와 UDP라는 프로토콜이 존재
4. 응용 계층
   • 응용프로그램들 간의 데이터 통신이 이루어지는 계층
   • 메일보내기( SMTP ), 파일 전송( FTP ), 웹에 접속( HTTP ) 

TCP/ IP 패킷 캡슐화 과정

TCP, UDP 프로토콜

TCP 프로토콜

• 연결 지향 프로토콜
• TCP 프로토콜에서는 데이터 송수신을 위해 클라이언트와 서버의 소켓이 연결되어 있어야 하며, 데이터가 유실되면 데이터 재전송을 요청함으로써 신뢰성을 보장
• 즉, 신뢰성 있는 데이터 전송이 가능하다는 장점으로 인해 HTTP, FTP, TELNET 등 대부분의 응용 계층 프로토콜의 전송 계층

UDP 프로토콜

• 비연결 지향 프로토콜입니다.
• 전송한 데이터가 잘 전달이 되었는지 확인하지 않고 단지 데이터만 보낸다는 점이 TCP와의 차이점
• 즉, 신뢰적이지 않으며( 비신뢰성 ), 대신 속도가 빠르다는 장점 존재. → 신뢰성 추가를 위해 헤더에 checksum 존재
•  UDP 프로토콜은 음악이나 동영상 스티리밍(streaming)과 같은 서비스에 적합

TCP 연결 / 해제 

TCP / IP 프로토콜은 OS 안에 라이브러리로 내장되어있고, 

연결을 위한 3 way handshake(클라이언트와 통신하기 전 3번의 악수)와 

종료를 위한 4 way handshake 의 과정들은 OS 에서 알아서 처리

# Socket : 응용 계층이 하위 계층인 TCP/IP 계층의 역할을 몰라도 되도록 TCP/IP 역할을 감춰주는 역할,
                 즉 소켓은 프로그래머가 커널 내부를 몰라도 TCP/IP 사용할 수있도록 하는 프로토콜 인터페이스

TCP 연결 : 3 way handshake

1. 클라이언트에서 서버에 연결 요청하는 SYN 데이터 전송
2. 서버가 SYN을 받으면 ACK+ SYN 를 클라이언트쪽에 포트를 열어달라는 데이터 전송
   • 서버 상태 : LISTEN → SYN_RCV 로 상태 변경
3. 클라이언트에서 서버로부터 해당 데이터를 받으면, 포트를 열고 확인을 위해 서버에 ACK 데이터 전송
   • 클라이언트 상태 : ESTABLISHED 상태로 변동
4. ACK 데이터를 받은 서버 역시 ESTABLISHED 상태로 변경되면서 클라이언트와 서버 연결 

TCP 종료 : 4 way handshake

1. 초기 상태 
   • 클라 : ESTABLISHED
   • 서버 : ESTABLISHED 
2. 클라이언트가 통신을 종료 하자는 FIN 데이터 전송 → 자신의 상태 종료 요청 후 ACK를 기다린다는 의미의 FIN_WAIT_1으로 상태 변동
3. 서버는 확인 후 클라이언트에 ACK 데이터를 보내며 애플리케이션 소켓 닫음
   • 서버 : 자원을 정리하는 데 시간이 소요되므로, CLOSE_WAIT 상태로 변동
   • 클라 : 서버로 부터 응답 올때 까지 기다린다는 FIN_WAIT_2 상태로 변동
4. 애플리케이션에서 소켓을 닫으면, 서버 → 클라이언트로 FIN 데이터 전송
   • 서버 : 클라로부터 받을 마지막 ACK 기다리는 LAST_ACK 상태로 변동
5. 클라이언트는 FIN 데이터 받으면 TIME_WAIT 상태로 변동되며 서버에서 ACK 데이터 보냄
   • 클라 : CLOSED
6. 서버 역시 ACK를 받았기 때문에 CLOSED

해당 과정에서 FIN_WAIT_1, FIN_WAIT_2  의 상태가 시간이 지나면 자동 TIME_OUT 되지만, 너무 그 시간텀이 길어서 많은 수의 소켓이 늘어난다면 

메모리 부족으로 소켓을 오픈하지 못하기 때문에, 

TIME OUT 시간을 적절히 조절할 필요가 있습니다. → 유닉스 환경에서 NDD 명령어 통해 확인 가능 

예시)

-- time_wait 종료 시간 확인

ndd -get /dev/tcp tcp_time_wait_interval



-- time_wait 종료 시간 30초로 설정

ndd -set /dev/tcp tcp_time_wait_interval 30000





-- fin_wait_2 타임 아웃 시간 확인

ndd -get /dev/tcp tcp_fin_wait_2_timeout



-- fin_wait_2 타임 아웃 시간 5분으로 설정

 ndd -set /dev/tcp tcp_fin_wait_2_timeout 300000

IP 확인

리눅스 - nslookup 명령어 사용

질의 방법

자주 사용되는 DNS Record type

-type의미

리눅스 명령어 예시

원하는 도메인 ip 확인 예시

C:Users780-32bit>nslookup simplexi.com

서버: ad-pdc.intra.simplexi.com

Address: 192.168.xx.90

이름: simplexi.com

Address: 222.122.xxx.6



C:Users780-32bit>nslookup www.simplexi.com

서버: ad-pdc.intra.simplexi.com

Address: 192.168.xx.90

이름: www.simplexi.com

Address: 222.122.xxx.6



C:Users780-32bit>nslookup mail.simplexi.com

서버: ad-pdc.intra.simplexi.com

Address: 192.168.xx.90

이름: mail.simplexi.com

Address: 203.231.xxx.10

특정 네임서버 통해서 ip 정보 확인

C:Users780-32bit>nslookup simplexi.com ns.dacom.co.kr

서버: ns.lgdacom.net

Address: 164.124.101.2

권한 없는 응답:

이름: simplexi.com

Address: 222.122.xxx.6



C:Users780-32bit>nslookup mail.simplexi.com kns.kornet.net

서버: kns.kornet.net

Address: 168.126.63.1

권한 없는 응답:

이름: mail.simplexi.com

Address: 203.231.xxx.10

1. 다운

$wget http://forum.falinux.com/_zdownload/data/ezboot.x5.v18.tar.gz

2. 압축 해제

tar -xvf ezboot.x5.v18.tar.gz

3. 내용물 확인

jisu@ubuntu:~$ cd v18.org
jisu@ubuntu:~/v18.org$ ls
eztiny  image  include  main  Makefile  start

image - 이지부트의 최종 이미지 파일이 들어감.

include - 이지부트 소스가 사용하는 헤더 파일이 있음.

main - C언어로 작성된 코드가 있음.

start - 어셈블리어로 작성된 보드 초기화 관련 코드들이 있음.

이지부트는 어셈블리 코드들이 컴파일 되어 한부분, main 이렉터리에 있는 C코드들이 컴파일되어 한부분을 이룹니다.

프로그램이 시작되면 맨처음 0번지에는 start에 있는 코드들이 실행(초기화라고 생각해라)된다. 그리고 실행이 끝나면 PC(Program Counter)에 main() 함수주소가 들어갑니다.(PC <- main() 주소)

4. 홈 디렉토리에 작업폴더 만들기!

jisu@ubuntu:~/v18.org/main$ cd ..
jisu@ubuntu:~/v18.org$ mkdir ~/navilnux
jisu@ubuntu:~/v18.org$ cp main ~/navilnux/chap2 -r
jisu@ubuntu:~/v18.org$ cp include ~/navilnux/chap2 -r

5. chap2폴더로 들어와 작업해봅시다

jisu@ubuntu:~/v18.org$ cd  ~/navilnux
jisu@ubuntu:~/navilnux$ ls
chap2
jisu@ubuntu:~/navilnux$ cd chap2
jisu@ubuntu:~/navilnux/chap2$ ls
arp_cmd.c      flash_cmd.c  lib1funcs.S     net.o       time.c
arp_cmd.o      flash_cmd.o  main.c          printf.c    time.o
config.c       go_cmd.c     main-elf32      printf.o    vscanf.c
config.o       go_cmd.o     main-ld-script  ram_cmd.c   vscanf.o
cs8900.c       gpio.c       main.o          ram_cmd.o   vsprintf.c
cs8900.o       gpio.o       main_org        serial.c    vsprintf.o
defaultlibs    help.c       Makefile        serial.o    zmodem.c
entry.o        help.o       Makefile.bak    string.c    zmodem_cmd.c
entry.S        include      nand.c          string.o    zmodem_cmd.o
flash_29lvx.c  info_cmd.c   nand.o          tftp_cmd.c  zmodem.o
flash_29lvx.o  lib1funcs.o  net.c           tftp_cmd.o

6. serial.c 파일을 수정합니다

• 헤더 파일에 있는 #include <config.h> 지움
  -> 이지부트 설정을 담고 있는 파일 
• extern TConfig Cfg;를 지움
  -> 이지부트 설정 담음
• void SerialInit( eBauds baudrate ) 함수를 다 지움
  -> 이지부트 설정 담음
• static volatitle Word *UART = (volatile Word *) STUART; 
  =>>>#ifdef IN_GUMSTIX static volatitle Word *UART = (volatile Word *) FFUART;
  #else static volatitl
  #endif
  -> UART : 컴퓨터 간에 통신 기능을 제공하는 기법
  -> 나빌눅스에서는 FULL FUNCTION UART를 사용
  ==> UART를 버퍼 주소로 변경해 준다
  -> volatile 는 컴파일러로부터 최적화를 막아주는 키워드

6. main.c를 그냥 다 지우고

navilux.c를 만들어서 하자

$rm main.c

$gedit navilnux.c

#include <pxa255.h>
#include <time.h>
#include <gpio.h>
#include <stido.h>
#include <string.h>

int main(void){
	while(1){
		printf("hello world\n");
		msleep(1000);
	}
}

//나빌눅스 c코드 / 1초마다 hello world를 출력

7.권한 주기

$chmod +x navilnux.c

8. 지워야할 항목 temp 폴더 만들어서 옮기기

jisu@ubuntu:~/navilnux/chap2$ chmod +x navilnux.c
jisu@ubuntu:~/navilnux/chap2$ mkdir temp
jisu@ubuntu:~/navilnux/chap2$ mv entry.S temp
jisu@ubuntu:~/navilnux/chap2$ mv gpio.c temp
jisu@ubuntu:~/navilnux/chap2$ mv lib1funcs.S temp
jisu@ubuntu:~/navilnux/chap2$ mv main-ld-script temp
jisu@ubuntu:~/navilnux/chap2$ mv navilnux.c temp
jisu@ubuntu:~/navilnux/chap2$ mv printf.c temp
jisu@ubuntu:~/navilnux/chap2$ mv serial.c temp
jisu@ubuntu:~/navilnux/chap2$ mv string.c temp
jisu@ubuntu:~/navilnux/chap2$ mv time.c temp
jisu@ubuntu:~/navilnux/chap2$ mv vsprintf.c temp

9. c 파일을 지움 삭제후 폴더에 보관했던 파일들을 꺼내오고 폴더를 삭제

$rm *.c
$cp temp/* .
$rm -r temp

10.헤더파일 정리

$cd include
$mkdir temp
$mv gpio.h temp
$mv pxa255.h temp
$mv serial.h temp
$mv stdarg.h temp
$mv stdio.h temp
$mv string.h temp
$mv time.h temp
$rm *.h
$rm 1
$cp temp/* .
$rm -r temp

11. Makefile 지웠다가 다시 만듬

CC = arm-linux-gcc

LD = arm-linux-ld

OC = arm-linux-objcopy

 

CFLAGS = -nostdinc -I. -I./include

CFLAGS += -Wall -Wstrict-prototypes -Wno-trigraphs -O2

CFLAGS += -fno-strict-aliasing -fno-common -pipe -mapcs-32

CFLAGS += -mcpu=xscale -mshort-load-bytes -msoft-float -fno-builtin

 

LDFLAGS = -static -nostdlib -nostartfiles -nodefaultlibs -p -X -T ./main-ld-script

 

OCFLAGS = -O binary -R .note -R .comment -S

all: navilnux.c

$(CC) -c $(CFLAGS) -o entry.o entry.S

$(CC) -c $(CFLAGS) -o gpio.o gpio.c

$(CC) -c $(CFLAGS) -o time.o time.c

$(CC) -c $(CFLAGS) -o vsprintf.o vsprintf.c

$(CC) -c $(CFLAGS) -o printf.o printf.c

$(CC) -c $(CFLAGS) -o string.o string.c

$(CC) -c $(CFLAGS) -o serial.o serial.c

$(CC) -c $(CFLAGS) -o lib1funcs.o lib1funcs.S

$(CC) -c $(CFLAGS) -o navilnux.o navilnux.c

$(LD) $(LDFLAGS) -o navilnux_elf entry.o gpio.o time.o vsprintf.o printf.o string.o serial.o lib1funcs.o navilnux.o

$(OC) $(OCFLAGS) navilnux_elf navilnux_img

$(CC) -c $(CFLAGS) -o serial.o serial.c -D IN_GUMSTIX

$(LD) $(LDFLAGS) -o navilnux_gum_elf entry.o gpio.o time.o vsprintf.o printf.o string.o serial.o lib1funcs.o navilnux.o

$(OC) $(OCFLAGS) navilnux_gum_elf navilnux_gum_img

 

clean:

rm *.o

rm navilnux_elf

rm navilnux_img

rm navilnux_gum_elf

rm navilnux_gum_img

12.

v18.org/ main / main.c 의 gokernel 확인

    	     	if ( getc_timed( Cfg.BootMenuKey, Cfg.AutoBootWaitTime*1000 ) )
    	     	{
       	     		//printf( "\r                                                                \n");  
       	     		printf( "\n");  
             		CopyImage();
             		GoKernel( 1, NULL );
             		// ¿©±â·Î ¿òÁ÷ÀÌÁö ŸÊŽÂŽÙ.
             		// ---
    	     	}
    	     	break;

13.v18.org/main/go_cmd.c 안의 함수 주소 확인

int 	GoKernelSingle( void )
{
    	char buff[] = { 0,0,0,0,0 }; // ží·É Ä¿žÇµå œÃÇè¿ëÀÓ 
    	void (*theKernel)(int zero, int arch);

	char kcmd[2048];
	int  len;
	
	// Ä¿³Î Ä¿žÇµå ¹®ÀÚ¿­À» ŸòŸî¿ÂŽÙ.
	memset( kcmd, 0, 2048 );
	len = GetKCmdStr( kcmd );	

    	printf( "Starting kernel [MARCH %d]...\n", Cfg.Kernel_ArchNumber );

    	memcpy( (char *) DEFAULT_RAM_KERNEL_ZERO_PAGE, kcmd, 2048 );

    	theKernel = (void (*)(int, int))DEFAULT_RAM_KERNEL_START; 
    	theKernel( ( long ) 0 , (long) Cfg.Kernel_ArchNumber );

    	return 0;
}

14.v18.org/include/mem_map.h 확인

#define DEFAULT_RAM_KERNEL_START        0xA0008000              // ·¥¿¡Œ­ Ä¿³Î     œÃÀÛ Ÿîµå·¹œº 
#define DEFAULT_RAM_RAMDISK_START       0xA0800000              // ·¥¿¡Œ­ ·¥µðœºÅ© œÃÀÛ Ÿîµå·¹œº 
#define DEFAULT_RAM_WORK_START          0xA1000000              // ÀϹÝÀûÀÎ ºÎÆ® ·ÎŽõ ÀÛŸ÷ ¿µ¿ª 

#define DEFAULT_RAM_KERNEL_ZERO_PAGE    0xA0000000              // ºÎÆ®·ÎŽõ¿¡Œ­ Ä¿³Î·Î ÀüŽÞÇÏŽÂ ¿µ¿ª œÃÀÛ Ÿîµå·¹œº 

#define DEFAULT_RAM_KERNEL_START 0xA0008000

​이라고 되어있습니다.

메모리 주소가 하나의 헤더파일에 정의되어 있는 것입니다.

이지부트가 실행이 끝나면, 즉. 커널이 실행되어야 할 주소입니다.

15.v18.org/main/main-ld-script 수정

change 0xA0F00800 to 0xA0008000.

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_ram_entry)
SECTIONS
{
	. = 0xA0008000;

	. = ALIGN(4);
	.text : { *(.text) }

	. = ALIGN(4);
	.rodata : { *(.rodata) }

	. = ALIGN(4);
	.data : { *(.data) }

	. = ALIGN(4);
	.got : { *(.got) }

	. = ALIGN(4);
	.bss : { *(.bss) }
}

make해서 이지부트 이미지 만들려고하는데 에러 나옴ㅎㅎ 울고싶다

include/pxa255.h:46:1: warning: this is the location of the previous definition
serial.c:41: error: syntax error before "Word"
serial.c:41: warning: initialization discards qualifiers from pointer target type
make: *** [all] Error 1